headers
Abin Xu | 21 May 2013 14:06
Picon

why the DSO was loaded at address 0

There is a simple test program,it dlopen()s a DSO "/lib/libc.so.6" and
then prints the address of symbol "printf".

#include <dlfcn.h>
#include <stdio.h>

int main() {
    void* handle;
    void (*func)();
    char* error_test;
    if (handle = dlopen("/lib/libc.so.6", RTLD_NOW)) {
        func = dlsym(handle, "printf");
        (*func)("address:%p\n",func);
        sleep(-1);
        dlclose(handle);
        return 0;
    }
    return -1;
}

When I debug it with "LD_DEBUG=all",it shows that:

[root <at> localhost glibc_test]# LD_DEBUG=all LD_DEBUG_OUTPUT=error ./test &
[18] 14690
[root <at> localhost glibc_test]# address:0x2f87b0

But the file "error" shows that "/lib/libc.so.6" was loaded to address
0! That`s why?
     14690:    initialize program: ./test
     14690:
(Continue reading)

Permalink | Reply | 5 comments |
headers
Edward Jee | 21 May 2013 01:14
Picon
Favicon

__bswap_constant_16 not compiled when -Werror -Wsign-conversion is given (32bit LE ARM)

Hi, may I ask a question?
I'm using gcc and glibc on 32bit LE ARM. And I found that the
following code is not compiled, if I give -Werror -Wsign-conversion
arguments to gcc.

#include <stdio.h>
#include <byteswap.h>

int main(int argc, char *argv[]) {
  unsigned short int x = 0xbeef;
  printf("bswap_16(0x%x)=0x%x\n", x, bswap_16(x));
  return 0;
}

I saw compilation error "conversion to 'unsigned int' from 'int' may
change the sign of the result".

It looks like that a similar issue has been solved for x86 by
http://sourceware.org/git/?p=glibc.git;a=commit;h=69da074d7adfab7b57004a0dea9403a928e310a5
.
But the architecture-independent bit/byteswap.h has not been modified
(I'm using that file).

Could someone tell me why this modification is not done for the
architecture-independent bit/byteswap.h ? Am I doing something wrong?

Thanks in advance.

--
Edward Hyun-koo Jee
(Continue reading)

Permalink | Reply | 4 comments |
headers
Aaron Davies | 14 May 2013 00:43
Picon

localeconv()->grouping n vs n;n?

Is there a difference between a localeconv()->grouping of 
"n" and one of "n;n"? On one host I have access to, there 
are 5 locales with grouping of "-1" and 128 with "-1;-1", 
and 83 with "3" and 192 with "3;3".
--

-- 
Aaron Davies
aaron.davies@...
Permalink | Reply | 0 comments |
headers
David Aldrich | 13 May 2013 16:33
Picon

Has dlopen() behaviour changed between libc 4.1 and libc 4.4?

Hi

We develop and maintain a fairly large C application which we build with the gcc 4.1 compiler suite and run
under Centos 5.  That is obviously a fairly old toolset set so we have been working on making the application
compatible with gcc 4.4.  This work program is almost complete but we have one problem that we are unable to
fix.  This problem is associated with the dlopen() function.

Our application executes simulations based on user-defined parameter files.  There are various
simulation models that can be run and we have separated the code for each model into a separate dynamic
library.  The parameter file specifies which models are required for a simulation and, therefore, which
dynamic libraries the core program ('kernel') must load before running the simulation.

The dynamic libraries have inter-dependencies, so they must be loaded in a certain order.  We can't rely on
the user to understand those dependencies so we load the libraries iteratively, keeping a record of which
ones failed to load, until all libraries have loaded successfully.

Here is the algorithm:

vector <string> notYetLoaded = a_LibFileNames;   // Load vector with full path of each library
bool failed = false;
std::vector<void*> m_dynamicLibHandles;

while (notYetLoaded.size()>0 && !failed) {
    vector <string> temp;

    for (unsigned i=0; i<notYetLoaded.size(); i++)
    {
        void* testHandle = dlopen(notYetLoaded[ind].c_str(),RTLD_NOW | RTLD_GLOBAL | RTLD_NOLOAD);   

        if (testHandle==NULL)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andreas Ames | 13 May 2013 13:07
Picon
Picon

Intercept ioctls

Hi all,

I have to tame a library that I can't change the source code of (although I have it).  Therefore I need to shim
glibc's ioctl function.  This is a little bit special as glibc's ioctl is declared with ellipsis.  Although
I'd prefer a portable solution the minimum requirements for the shim are to be functional on i386 an 32bit
PowerPC architectures.  I'd appreciate if you could help me with the following issues.

The examples intercepting ioctl that I can find in the web forward the ioctl call with a third argument of
type 'void*' like the following:

int ioctl(int fd, int request, ...)
{
	va_list args;
	void* argp;
	int res;

	va_start(args, request);
	argp = va_arg(args, void*); /* Is that really safe? */
	va_end(args);

	res = (*real_libc_ioctl)(fd, request, argp);
	/* do my specific stuff here */

	return res;
}

What I'm concerned about is whether it's 'safe' enough to use a void* argument here.  For instance, I know
there are ioctls like TIOCSBRK or TIOCCBRK that don't expect any argument.  My guess is that the above shim
would be functional at least on the relevant architectures with no-third-argument ioctls:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Miguel Guedes | 11 May 2013 13:37
Picon
Gravatar

Bug in getopt_long under specific circumstances when non-options present

Hello list,

I believe I have found a bug in getopt_long which manifests itself only 
in very specific situations when non-options are present in argv.

If you run the included small program (see below) as follows: 

$ ./test create --set=test test --invalid
--set
./test: unrecognized option '--invalid'
bad long opt "test"

... you can see getopt_long correctly identifies `--invalid' as not being 
a valid long option (./test: unrecognized option '--invalid') but `optind' 
doesn't seem to be set correctly which results in the output of the wrong 
option by the test program (bad long opt "test").

I haven't had a look in libc's source code but it seems that `optind' is 
indeed set wrongly under very specific circumstances unless I'm wrong. 

Can someone confirm this?

-- test program follows --

#include <getopt.h>
#include <stdio.h>

int main(int argc, char **argv)
{
  struct option longopts[] = {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Karthikeyan Shanmugam | 7 May 2013 22:14
Picon
Favicon

RE: Regarding "Inconsistency detected by ld.so" 32 Bit Elf

Thanks Carlos for your reply.

The prelink tool and method is working fine, but the required linking libraries can change during the
product life cycle (explained detail in below).

In short (objective), attempting to reserve the VMA (00020000 - 22000000 ) for an application using linker
script to avoid shared libraries fall in between these desired VMA.

The base address (first PT_LOAD VMA) of ld.so (0ffc0000) and libc (0fe40000) in my system is conflicting
with application desired address which failed the application load (due to desired range not available).

 With respect to linker script :

 - Modified default PPC 32 linker script
 - Assigned application base address (first PT_LOAD)  <at>  28000000
 - Included required PHDR and assigned all sections according to PHDR
 - Included dummy section (for the desired address range)
 - Complied executable with modified linker script using -T <linker option
 - Created -Map to verified new section is properly included and allocation (desired size)

 While attempting to load the binary (custom linked) received failure message from dl-open.c

 "Inconsistency detected by ld.so: dl-open.c: 593: _dl_open: Assertion `_dl_debug_initialize (0,
args.nsid)-r_state == RT_CONSISTENT' failed!"

 The above failure application was due to an attempt to open its own library with (RTLD_NOW | RTLD_LOCAL)
option - This dlopen function is working fine without dummy section.

 So wondering the failure is only due to the included section or due to some open hold in dl-open code.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Karthikeyan Shanmugam | 6 May 2013 21:44
Picon
Favicon

Regarding "Inconsistency detected by ld.so" 32 Bit Elf

Hi All,

I'm working custom 32 Bit PPC linker script in order to tweak the user level process memory allocation/reservation:

I've one standalone application (32 - Bit) for which need contiguous memory layout. Due to the shared
libraries falling in a place (libc  <at> 0fe40000 and ld  <at> 0ffc0000) which is blocking us from using contiguous
memory (lower part). 

I tried certain things with prelink tool to relocate those libraries and able to successfully to relocate
in expected place. But, I like to achieve the same thing using linker script tweak. 

I believe during process instantiation, When the dynamic loader seeks for the unmapped region there is no
mmap in area 0x0f... which resulted in placing the shared libraries  <at> 0x0f... 

By default PPC linker is using "-z combreloc" script. I've created one custom linker script on top of
comroloc after adding a fack section  <at> 0x0f... which resulted in "Inconsistency error" 

Without fake section, custom linker script is working fine. ASLR - PAX and all other randomization are
disabled in my system.

Below is an attempt to create a fake block between (00020000 - 0fffffff) with custom linker section
included  which resulted libdl to fall  <at> 0fe20000 and executable loading is failing with error message
"Inconsistency detected by ld.so".

PHDR

TSTSTART PT_LOAD FLAGS (0);

SECTION
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Richter | 3 May 2013 17:11
Picon
Favicon

*** SPAM LEVEL 4.448 *** Dynamic linker behaviour difference between Linux, Hurd and FreeBSD

Hi,

I'm writing a small preload library to trace pthread_* calls, and am
running into a bit of a chicken-and-egg problem.

In order to find the original function, I use dlsym(RTLD_NEXT, ...) to
look up the symbol on the first invocation. On Linux, this works find,
however on the Hurd and on FreeBSD, the libdl invokes pthread_once,
which is then dispatched into my preload library, where I still haven't
found the real function.

This could be due to a difference in dlsym() implementation (so it is
sheer luck that it works on Linux), or a true behavioural difference
between platforms.

In any case, I am wondering if it is actually possible to redirect the
pthread_* functions in this way, or if a different approach is required.

LD_DEBUG=all output is attached for Linux (good) and FreeBSD (bad).
Program source[1] is also available.

   Simon

[1] http://www.hogyros.de/download/mutextrace-0.1.2.tar.gz
Attachment (good.bz2): application/octet-stream, 5362 bytes
Attachment (bad.bz2): application/octet-stream, 5908 bytes
Permalink | Reply | 4 comments |
headers
Aron Ahmadia | 28 Apr 2013 23:48
Gravatar

Re: What does ld.so do that dlopen don't do when loading shared libraries

I'll second Ondrej here, the TAU developers should understand why their
code is working for one and not the other, or at least point us to the
relevant pieces of the TAU source that load the profiling bits.  Your
actual source code is irrelevant here :)

A
Permalink | Reply | 0 comments |
headers
Celelibi | 28 Apr 2013 23:08
Picon

What does ld.so do that dlopen don't do when loading shared libraries

Hello there,

This is my first message to this mailing list. ^^

And I have a question that may be quite unusual: What does ld.so do
that dlopen don't do when loading shared libraries?

A bit of explanation may be needed. There is a profiler named TAU
<tau.uoregon.edu> which can instrument files it compiles and then
generate a file profile.0.0.0 when the program is run. Much like
compiling with gcc -pg.

And I can do things like: compile a shared library with tau_cc (which
instrument the shared object) and then link it with a simple program.
tau_cc.sh -shared -fPIC -o foo.so foo.c
gcc -o sep sep.c foo.so

This works fine, running ./sep produce the profile trace. (That
wouldn't work with gprof.)

However, if I dlopen/dlsym the library instead of linking against it,
it doesn't produce any file.
tau_cc.sh -shared -fPIC -o foo.so foo.c
gcc -o dyn dyn.c

Therefore I guess ld.so does something special when it loads the
needed library that dlopen doesn't do. I think about ctor/entrypoint
execution, but I have no clue to find out.

I join foo.c sep.c and dyn.c as an example.
(Continue reading)

Permalink | Reply | 7 comments |

Gmane