This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [Various] libc/1609: Error in 'make check' origtest with

> >> This can cause some application bugs or limitations to show up.
> >> This can well be a bug in my code, I'm just pointing out that we
> >> can't be sure of that, yet.
> Ulrich> There are no such dependencies.  We use the same code on different
> Ulrich> platforms which use different shared lib positions.  Also, loading
> Ulrich> shared objects (including in different orders gives different
> Ulrich> load addresses.  I'm pretty sure this cannot be the problem.
> When debugging the problem, I noticed that the following piece of code
> from dl-open seemed to assign the wrong address:

Could you quote the exact "right" and "wrong" addresses this code
produces (indeed the address _should_ change when the kernel patch is
enabled; I am just hoping to get an idea of what is going on from the

>       /* We have to find out from which object the caller is calling.
> 	 Find the highest-addressed object that ADDRESS is not below.  */
>       call_map = NULL;
>       for (l = _dl_loaded; l; l = l->l_next)
> 	if (l->l_addr != 0 /* Make sure we do not currently set this map up
> 			      in this moment.  */
> 	    && caller >= (const void *) l->l_addr
> 	    && (call_map == NULL || call_map->l_addr < l->l_addr))
> 	  call_map = l;

Does the _dl_loaded list only have shared libraries on it (and not,
say, the ELF sections as well)?

JFYI, the patch changes the default mmap(2) start address to 0x110000
(1MB+64K not to break dosemu), from 0x40000000 for the default memory
configuration.  Note that the address changes from above 0x8048000 to
below the ELF sections.  This holds true for other reasonable memory
configurations as supported by recent kernels.  All this stuff is x86
specific, of course.

On alpha, the ELF sections are at 0x120000000, while shared libraries
get loaded at 0x20000000000, which matches the same rule.  My theory
breaks with sparc, though...

Solar Designer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]