[parisc-linux] /lib/ld.so.1 (glibc) issues on parisc-linux 2.5 kernel??

[parisc-linux] /lib/ld.so.1 (glibc) issues on parisc-linux 2.5 kernel??

[Ryan Bradetich]

Hello libc hackers,

I am investigating a problem that occurs between ld.so.1
and the kernel on the 2.4 (w/o the added hack to fix this) and 2.5 
kernels. The problem manifested itself when I tried to run the ltp
tests, and is shown below:


rbrad@vega:~$ /lib/ld.so.1 --verify /bin/sh
Inconsistency detected by ld.so: rtld.c: 879: dl_main: Assertion
`_rtld_local._dl_rtld_map.l_libname' failed!


The system is running Debian Linux with this version of glibc:
ii  libc6          2.3.1-14       GNU C Library: Shared libraries and


The complete email thread on the parisc-linux list is located at:

http://lists.parisc-linux.org/pipermail/parisc-linux/2003-March/019460.html




I have basically tracked this mis-match down to this problem:

With this statement in the kernel (fs/binfmt_elf.c:create_elf_tables())

	NEW_AUX_ENT(AT_ENTRY, exec->e_entry);

The user_entry and ENTRY_POINTS are:

	user_entry: 41001fb4
	ENTRY_POINT: 41027082


With this statement not present, and the interpreter_type == 0 (No
Interpreter) .. the user_entry and ENTRY_POINT match.  [Note: The
assert goes away at this point].

	user_entry: 41027082
	ENTRY_POINT: 41027082


So at this point, I am not sure if the kernel is setting the
exec->e_entry incorrectly, or if the ENTRY_POINT needs to be adjusted
in glibc for the hppa platform.


Carlos O'Donell suggested I forward this message to this list for
additional advice.  Please cc me on any replies since I am not
subscribed to this list.

Thanks,

- Ryan


-- 
Ryan Bradetich <rbradetich@uswest.net>

[parisc-linux] /lib/ld.so.1 (glibc) issues on parisc-linux 2.5 kernel??

[Ryan Bradetich]

Hello libc hackers,

I am investigating a problem that occurs between ld.so.1
and the kernel on the 2.4 (w/o the added hack to fix this) and 2.5 
kernels. The problem manifested itself when I tried to run the ltp
tests, and is shown below:


rbrad@vega:~$ /lib/ld.so.1 --verify /bin/sh
Inconsistency detected by ld.so: rtld.c: 879: dl_main: Assertion
`_rtld_local._dl_rtld_map.l_libname' failed!


The system is running Debian Linux with this version of glibc:
ii  libc6          2.3.1-14       GNU C Library: Shared libraries and


The complete email thread on the parisc-linux list is located at:

http://lists.parisc-linux.org/pipermail/parisc-linux/2003-March/019460.html




I have basically tracked this mis-match down to this problem:

With this statement in the kernel (fs/binfmt_elf.c:create_elf_tables())

	NEW_AUX_ENT(AT_ENTRY, exec->e_entry);

The user_entry and ENTRY_POINTS are:

	user_entry: 41001fb4
	ENTRY_POINT: 41027082


With this statement not present, and the interpreter_type == 0 (No
Interpreter) .. the user_entry and ENTRY_POINT match.  [Note: The
assert goes away at this point].

	user_entry: 41027082
	ENTRY_POINT: 41027082


So at this point, I am not sure if the kernel is setting the
exec->e_entry incorrectly, or if the ENTRY_POINT needs to be adjusted
in glibc for the hppa platform.


Carlos O'Donell suggested I forward this message to this list for
additional advice.  Please cc me on any replies since I am not
subscribed to this list.

Thanks,

- Ryan


-- 
Ryan Bradetich <rbradetich@uswest.net>

[parisc-linux] /lib/ld.so.1 (glibc) issues on parisc-linux 2.5 kernel??

[Ryan Bradetich]

Hello again,

I have been working on tracking this down some more, and I think I found
something odd.  I just wanted to verify this is an anomaly (and
potentially the problem) or if this is the correct behavior, understand
why.


I am starting to think the kernel is doing the correct thing and
glibc is causing the problem ... based on debug output from i386
and just my general understanding (or lack of understanding :))
of the elf file format.

The bootstrap_map.l_addr was printed using _dl_debug_printf right
after the following line in glibc-2.3.1/elf/rtld.c:

	      ELF_DYNAMIC_RELOCATE (&bootstrap_map, 0, 0);

The ENTRY_POINT, _start, and user_entry line was added as the first
line of code in the function dl_main in glibc-2.3.1/elf/rtld.c.

This is the debug output on hppa:
---------------------------------
rbrad@vega:~/glibc-2.3.1/hppa-linux/obj/elf$ ./ld.so --verify /bin/sh

05626:  bootstrap_map.l_addr: 41000000
05626:  ENTRY_POINT: 41027162 _start: 41027162 user_entry: 41001ff0


This is the Entry point address from the ld.so library on hppa:
---------------------------------------------------------------
rbrad@vega:~/glibc-2.3.1/hppa-linux/obj/elf$ readelf -a ld.so | grep
Entry
  Entry point address:               0x1ff0




This is the debug output on i386:
---------------------------------
rbrad@beavis:~/debug/glibc-2.3.1/i386-linux/obj/elf$ ./ld.so --verify
/bin/sh
18878:  bootstrap_map.l_addr: 80000000
18878:  ENTRY_POINT: 80000b10 _start: 80000b10 user_entry: 80000b10


This is the Entry point address from the ld.so library on i386:
---------------------------------------------------------------
rbrad@beavis:~glibc-2.3.1/i386-linux/obj/elf$ readelf -a ld.so | grep
Entry
  Entry point address:               0xb10



The i386 library makes sense to me: the bootstrap_map.l_addr + the
_start == the user_entry point. On hppa, this is not true, and I 
do not understand why.  The reason why this works when the AT_ENTRY
aux header is not added is because the user_entry defaults to
ENTRY_POINT, and is modified iff the aux AT_ENTRY header is present.
[Note: this code is at:
   glibc-2.3.1/sysdeps/generic/dl-sysdep.c:_dl_sysdep_start()]


Is there a bug in the dynamic loader for hppa that doesn't load the 
address at load_address + _start?  Or can someone explain why there
is an additional 0x25172 byte offset for the entry point? 

I will keep digging around and see what I can dig up, but without
understanding how the dynamic loader works, I feel pretty blind.

Thanks,

- Ryan

P.S. Please cc me on any responses... I am not subscribed to this
list.


-- 
Ryan Bradetich <rbradetich@uswest.net>

[parisc-linux] /lib/ld.so.1 (glibc) issues on parisc-linux 2.5 kernel??

[Ryan Bradetich]

Hello again,

I have been working on tracking this down some more, and I think I found
something odd.  I just wanted to verify this is an anomaly (and
potentially the problem) or if this is the correct behavior, understand
why.


I am starting to think the kernel is doing the correct thing and
glibc is causing the problem ... based on debug output from i386
and just my general understanding (or lack of understanding :))
of the elf file format.

The bootstrap_map.l_addr was printed using _dl_debug_printf right
after the following line in glibc-2.3.1/elf/rtld.c:

	      ELF_DYNAMIC_RELOCATE (&bootstrap_map, 0, 0);

The ENTRY_POINT, _start, and user_entry line was added as the first
line of code in the function dl_main in glibc-2.3.1/elf/rtld.c.

This is the debug output on hppa:
---------------------------------
rbrad@vega:~/glibc-2.3.1/hppa-linux/obj/elf$ ./ld.so --verify /bin/sh

05626:  bootstrap_map.l_addr: 41000000
05626:  ENTRY_POINT: 41027162 _start: 41027162 user_entry: 41001ff0


This is the Entry point address from the ld.so library on hppa:
---------------------------------------------------------------
rbrad@vega:~/glibc-2.3.1/hppa-linux/obj/elf$ readelf -a ld.so | grep
Entry
  Entry point address:               0x1ff0




This is the debug output on i386:
---------------------------------
rbrad@beavis:~/debug/glibc-2.3.1/i386-linux/obj/elf$ ./ld.so --verify
/bin/sh
18878:  bootstrap_map.l_addr: 80000000
18878:  ENTRY_POINT: 80000b10 _start: 80000b10 user_entry: 80000b10


This is the Entry point address from the ld.so library on i386:
---------------------------------------------------------------
rbrad@beavis:~glibc-2.3.1/i386-linux/obj/elf$ readelf -a ld.so | grep
Entry
  Entry point address:               0xb10



The i386 library makes sense to me: the bootstrap_map.l_addr + the
_start == the user_entry point. On hppa, this is not true, and I 
do not understand why.  The reason why this works when the AT_ENTRY
aux header is not added is because the user_entry defaults to
ENTRY_POINT, and is modified iff the aux AT_ENTRY header is present.
[Note: this code is at:
   glibc-2.3.1/sysdeps/generic/dl-sysdep.c:_dl_sysdep_start()]


Is there a bug in the dynamic loader for hppa that doesn't load the 
address at load_address + _start?  Or can someone explain why there
is an additional 0x25172 byte offset for the entry point? 

I will keep digging around and see what I can dig up, but without
understanding how the dynamic loader works, I feel pretty blind.

Thanks,

- Ryan

P.S. Please cc me on any responses... I am not subscribed to this
list.


-- 
Ryan Bradetich <rbradetich@uswest.net>

Re: [parisc-linux] /lib/ld.so.1 (glibc) issues on parisc-linux 2.5 kernel??

[Andreas Schwab]

Ryan Bradetich <rbradetich@uswest.net> writes:

|> Hello again,
|> 
|> I have been working on tracking this down some more, and I think I found
|> something odd.  I just wanted to verify this is an anomaly (and
|> potentially the problem) or if this is the correct behavior, understand
|> why.
|> 
|> 
|> I am starting to think the kernel is doing the correct thing and
|> glibc is causing the problem ... based on debug output from i386
|> and just my general understanding (or lack of understanding :))
|> of the elf file format.
|> 
|> The bootstrap_map.l_addr was printed using _dl_debug_printf right
|> after the following line in glibc-2.3.1/elf/rtld.c:
|> 
|> 	      ELF_DYNAMIC_RELOCATE (&bootstrap_map, 0, 0);
|> 
|> The ENTRY_POINT, _start, and user_entry line was added as the first
|> line of code in the function dl_main in glibc-2.3.1/elf/rtld.c.
|> 
|> This is the debug output on hppa:
|> ---------------------------------
|> rbrad@vega:~/glibc-2.3.1/hppa-linux/obj/elf$ ./ld.so --verify /bin/sh
|> 
|> 05626:  bootstrap_map.l_addr: 41000000
|> 05626:  ENTRY_POINT: 41027162 _start: 41027162 user_entry: 41001ff0

hppa is using function descriptors, AFAIK.  So you'll have to do something
similar to what ia64 and ppc64 are doing.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [parisc-linux] /lib/ld.so.1 (glibc) issues on parisc-linux 2.5 kernel??

[Andreas Schwab]

Ryan Bradetich <rbradetich@uswest.net> writes:

|> Hello again,
|> 
|> I have been working on tracking this down some more, and I think I found
|> something odd.  I just wanted to verify this is an anomaly (and
|> potentially the problem) or if this is the correct behavior, understand
|> why.
|> 
|> 
|> I am starting to think the kernel is doing the correct thing and
|> glibc is causing the problem ... based on debug output from i386
|> and just my general understanding (or lack of understanding :))
|> of the elf file format.
|> 
|> The bootstrap_map.l_addr was printed using _dl_debug_printf right
|> after the following line in glibc-2.3.1/elf/rtld.c:
|> 
|> 	      ELF_DYNAMIC_RELOCATE (&bootstrap_map, 0, 0);
|> 
|> The ENTRY_POINT, _start, and user_entry line was added as the first
|> line of code in the function dl_main in glibc-2.3.1/elf/rtld.c.
|> 
|> This is the debug output on hppa:
|> ---------------------------------
|> rbrad@vega:~/glibc-2.3.1/hppa-linux/obj/elf$ ./ld.so --verify /bin/sh
|> 
|> 05626:  bootstrap_map.l_addr: 41000000
|> 05626:  ENTRY_POINT: 41027162 _start: 41027162 user_entry: 41001ff0

hppa is using function descriptors, AFAIK.  So you'll have to do something
similar to what ia64 and ppc64 are doing.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [parisc-linux] /lib/ld.so.1 (glibc) issues on parisc-linux 2.5 kernel??

[Ryan Bradetich]

> hppa is using function descriptors, AFAIK.  So you'll have to do something
> similar to what ia64 and ppc64 are doing.

Thanks much for the reply!  I will investigate the function descriptors and
see if that accounts for the different in offsets.  If so, I just need to
figure out which side needs to be fixed :)

Thanks!

- Ryan

> Andreas.
> 
> -- 
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> 

-- 

Re: [parisc-linux] /lib/ld.so.1 (glibc) issues on parisc-linux 2.5 kernel??

[Ryan Bradetich]

> hppa is using function descriptors, AFAIK.  So you'll have to do something
> similar to what ia64 and ppc64 are doing.

Thanks much for the reply!  I will investigate the function descriptors and
see if that accounts for the different in offsets.  If so, I just need to
figure out which side needs to be fixed :)

Thanks!

- Ryan

> Andreas.
> 
> -- 
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> 

-- 

Re: [parisc-linux] /lib/ld.so.1 (glibc) issues on parisc-linux 2.5 kernel??

[H. J. Lu]

On Mon, Mar 24, 2003 at 11:44:47AM -0700, Ryan Bradetich wrote:
> > hppa is using function descriptors, AFAIK.  So you'll have to do something
> > similar to what ia64 and ppc64 are doing.
> 
> Thanks much for the reply!  I will investigate the function descriptors and
> see if that accounts for the different in offsets.  If so, I just need to
> figure out which side needs to be fixed :)
> 

I posted a patch a long time ago to unify function descriptor handling
such that ia64 and pa-risc don't have to reinvent the wheel.


H.J.

Re: [parisc-linux] /lib/ld.so.1 (glibc) issues on parisc-linux 2.5 kernel??

[H. J. Lu]

On Mon, Mar 24, 2003 at 11:44:47AM -0700, Ryan Bradetich wrote:
> > hppa is using function descriptors, AFAIK.  So you'll have to do something
> > similar to what ia64 and ppc64 are doing.
> 
> Thanks much for the reply!  I will investigate the function descriptors and
> see if that accounts for the different in offsets.  If so, I just need to
> figure out which side needs to be fixed :)
> 

I posted a patch a long time ago to unify function descriptor handling
such that ia64 and pa-risc don't have to reinvent the wheel.


H.J.

[parisc-linux] Function descriptors fall behind Sysdep-cancel, Less failures, and ABI files for Roland.

[Carlos O'Donell]

> I posted a patch a long time ago to unify function descriptor handling
> such that ia64 and pa-risc don't have to reinvent the wheel.

Your patch is definately the correct way to go. When I initially
recommended that Ryan take the issue to the list I didn't realize it was
a function descriptor issue.  

Unfortunately it falls behind the following changes:
	- Sysdep-cancel support.
	- Building glibc without severe testsuite failures
	- Handing Roland the ABI files for HPPA.

After this I plan to follow up on the required function descriptor 
changes, all along the lines of the current ia64/ppc64 implementation.

Current HPPA glibc status:
- New LinuxThreads that doesn't require explicit alignment of locks.
- 2.3.2 builds, various failures.
- Fixing sysdep-cancel support.

I should start sending the patches back here soon.

c.

[parisc-linux] Function descriptors fall behind Sysdep-cancel, Less failures, and ABI files for Roland.

[Carlos O'Donell]

> I posted a patch a long time ago to unify function descriptor handling
> such that ia64 and pa-risc don't have to reinvent the wheel.

Your patch is definately the correct way to go. When I initially
recommended that Ryan take the issue to the list I didn't realize it was
a function descriptor issue.  

Unfortunately it falls behind the following changes:
	- Sysdep-cancel support.
	- Building glibc without severe testsuite failures
	- Handing Roland the ABI files for HPPA.

After this I plan to follow up on the required function descriptor 
changes, all along the lines of the current ia64/ppc64 implementation.

Current HPPA glibc status:
- New LinuxThreads that doesn't require explicit alignment of locks.
- 2.3.2 builds, various failures.
- Fixing sysdep-cancel support.

I should start sending the patches back here soon.

c.