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

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

[Ryan Bradetich]

Got a wierd glibc/kernel problem...

This all started by simply trying to run the ltp tests on the linux 2.5
kernel.  

The ltp tests run the ldd command, which we tracked down to this
final command: /lib/ld.so.1 --verify /bin/sh

Note: The --verify /bin/sh is irrelevant for the purpose of these
errors, /lib/ld.so.1 displays this problem w/o any additional
arguments.  


Linux vega 2.5.64-pa5 #3 Sun Mar 16 23:44:38 MST 2003 parisc unknown
unknown GNU/Linux
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!
rbrad@vega:~$

With the same system, but running the 2.4 kernel .... everything
seems to work fine.

rbrad@vega:~$ uname -a
Linux vega 2.4.20-pa28 #1 Sun Mar 16 10:13:17 MST 2003 parisc unknown
unknown GNU/Linux
rbrad@vega:~$ /lib/ld.so.1 --verify /bin/sh
rbrad@vega:~$


This box is running a 32-bit kernel and is running almost TOB unstable.

Installed libc6 is:
ii  libc6          2.3.1-14       GNU C Library: Shared libraries and
Timezone

Installed bash is:
ii  bash           2.05b-7        The GNU Bourne Again SHell


What is _really_ strange is that the system works ... even even though
/lib/ld.so.1 is throwing that assert.  I did not notice this
error until trying to run the ltp tests.

Any thoughts?

Thanks,

- Ryan

-- 
Ryan Bradetich <rbradetich@uswest.net>

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

[Matthew Wilcox]

On Mon, Mar 17, 2003 at 09:19:14AM -0700, Ryan Bradetich wrote:
> Linux vega 2.5.64-pa5 #3 Sun Mar 16 23:44:38 MST 2003 parisc unknown
> unknown GNU/Linux
> 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!
> rbrad@vega:~$
> 
> With the same system, but running the 2.4 kernel .... everything
> seems to work fine.

Hmm.  Back in 2.4, we had an RGH_HACK in fs/binfmt_elf.c which (iirc)
was introduced to stop this error.  I'm not sure we ever tracked down the
problem this was solving, but we thought it'd gone away with recent glibc.

I guess not.  I'm reluctant to bring the RGH_HACK forwards... but if
someone did, it might help track down where this problem really is.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

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

[Ryan Bradetich]

Good call willy!


> Hmm.  Back in 2.4, we had an RGH_HACK in fs/binfmt_elf.c which (iirc)
> was introduced to stop this error.  I'm not sure we ever tracked down the
> problem this was solving, but we thought it'd gone away with recent glibc.
> 
> I guess not.  I'm reluctant to bring the RGH_HACK forwards... but if
> someone did, it might help track down where this problem really is.

#undef the RGH_FIX in fs/binfmt_elf.c produces the same behaviour
on 2.4 as well.

Hopefully this will give someone a hint on the real problem.

Thanks!

- Ryan

-- 
Ryan Bradetich <rbradetich@uswest.net>

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

[Ryan Bradetich]

I have spend some more time tracking this problem down.

I have found the offending line in the kernel that causes
this problem, the rest of the RGH_FIX can be eliminated.

The symptom is with this line: 
	NEW_AUX_ENT(AT_ENTRY, exec->e_entry);

in fs/binfmt_elf.c:create_elf_tables().

If the that line is executed when the 
interpreter_type == INTERPRETER_NONE, the error shows up when
/lib/ld.so.1 is executed.  This line is fine when when the
interpreter_type == INTERPRTER_ELF ... which explains why
the system runs normally, and the error only manifests itself
when /lib/ld.so.1 is executed by hand.  (the /lib/ld.so.1 library 
does not set a PT_INTERP, so the interpreter is not set, where as
if a binary is executed, the interpreter is set to ELF).


The assert caused by /lib/ld.so.1 is caused by this line
in rtld.c:

	assert (GL(dl_rtld_map).l_libname); /* How else did we get here?  */

This assert is in the else clause of this if statement:


  if (! GL(dl_rtld_map).l_libname && GL(dl_rtld_map).l_name)


The whole purpose of this if statment, according to the comments,
is to deal with this senario, where the library was invoked directly,
and the PT_INTERP was not set.


I am rebuilding glibc from source on my C200 now (i.e. this will
probably take a while :)) and I will continue debugging. I just wanted
to give a status update in case someone else has an idea, or was working
on it.

Thanks,

- Ryan


-- 
Ryan Bradetich <rbradetich@uswest.net>

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

[Ryan Bradetich]

Continuing to track this problem down, I have found the
following:

The Problem appears to be that when the 

	NEW_AUX_ENT(AT_ENTRY, exec->e_entry)

is called, it puts in the wrong entry point.

The reason I believe the error manifests itself is because
of this if statment:

  if (*user_entry == (ElfW(Addr)) ENTRY_POINT)

I have tracked down values of the user_entry and ENTRY_POINT:

	user_entry: 41001fb4
	ENTRY_POINT: 41027082

Since they are different, the if statement fails... My belief
is they should be the same when /lib/ld.so.1 is called because
of the following comment inside this if statement:


      /* Ho ho.  We are not the program interpreter!  We are the program
         itself!  This means someone ran ld.so as a command.  Well, that
         might be convenient to do sometimes.  We support it by
         interpreting the args like this:
                                                                                
         ld.so PROGRAM ARGS...
 
         The first argument is the name of a file containing an ELF
         executable we will load and run with the following arguments.
         To simplify life here, PROGRAM is searched for using the
         normal rules for shared objects, rather than $PATH or anything
         like that.  We just load it and use its entry point; we don't
         pay attention to its PT_INTERP command (we are the interpreter
         ourselves).  This is an easy way to test a new ld.so before
         installing it.  */



to me there looks like two things that could be wrong:

1.  The exec->e_entry needs to be fixed in the kernel, so it matches
    the _start of the library.

2.  The ENTRY_POINT needs to be changed in glibc for parisc-linux.


ia64 seems to be the only arch that changes the value of ENTRY_POINT,
so this doesn't seem likely...

./glibc-2.3.1/sysdeps/generic/entry.h:#define ENTRY_POINT _start
./glibc-2.3.1/sysdeps/ia64/elf/entry.h:#define ENTRY_POINT (((long int
*) _start)[0])



I am planning to pursue option 1 unless someone thinks option 2 is the
correct option to pursue.


Thanks,

- Ryan


-- 
Ryan Bradetich <rbradetich@uswest.net>

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

[Carlos O'Donell]

Ryan,

> 	user_entry: 41001fb4
> 	ENTRY_POINT: 41027082

Intereting...
 
> Since they are different, the if statement fails... My belief
> is they should be the same when /lib/ld.so.1 is called because
> of the following comment inside this if statement:

I wouldn't trust code comments.
 
> to me there looks like two things that could be wrong:
> 
> 1.  The exec->e_entry needs to be fixed in the kernel, so it matches
>     the _start of the library.
> 
> 2.  The ENTRY_POINT needs to be changed in glibc for parisc-linux.
> 
> I am planning to pursue option 1 unless someone thinks option 2 is the
> correct option to pursue.

Would you be willing to ask this question on
libc-alpha@sources.redhat.com? If not, I could push the question out
there and see what the official solution should be and why.

I'm interested to know why this broke? :)

c.