[parisc-linux] dynamic loader problem

[parisc-linux] dynamic loader problem

[John David Anglin]

In looking at the the failure of the g++.brendan/new3.C, I have observed
what appears to be a problem with the dynamic loader.  The function
_Znwj appears as a global symbol in the main program and in
libstdc++.so.4.0.0.  The version in the main program should be selected
in preference to the one in the shared library.  However, the dynamic
loader actually uses the version in the shared library causing the
test to fail.  The program works ok with static linkage.

It looks like the symbol search procedure used in glibc needs some work.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] dynamic loader problem

[Randolph Chung]

Dave, FYI I upgraded a bunch of stuff on gsyprf11.... let me know if you
see any new breakage. In particular I think bash should be in better
shape now.

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] dynamic loader problem

[John David Anglin]

> Dave, FYI I upgraded a bunch of stuff on gsyprf11.... let me know if you
> see any new breakage. In particular I think bash should be in better
> shape now.

The biggest issue on gsyprf11 is the filling of the log file with page
faults.  I've more or less given up running the gcc testsuite because
expect almost always seems to get into a state where it causes an
enormous number of page faults and then hangs when when the /var
file system is full.  I have noticed that various pthread test
programs in the libstdc++ testsuite also cause many page faults.
It's possible this problem is specific to 64-bit machines.

There haven't been as many random seg faults recently.

Has anybody worked on the various "dl-" routines in glibc/sysdeps/hppa
recently?  That's probably where the dynamic loader problem lies.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] dynamic loader problem

[Randolph Chung]

> Has anybody worked on the various "dl-" routines in glibc/sysdeps/hppa
> recently?  That's probably where the dynamic loader problem lies.

afaik ESIEE guys are looking at glibc.... thibaut? clement? any comments?

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] dynamic loader problem

[Randolph Chung]

In reference to a message from John David Anglin, dated Mar 11:
> In looking at the the failure of the g++.brendan/new3.C, I have observed
> what appears to be a problem with the dynamic loader.  The function
> _Znwj appears as a global symbol in the main program and in
> libstdc++.so.4.0.0.  The version in the main program should be selected
> in preference to the one in the shared library.  However, the dynamic
> loader actually uses the version in the shared library causing the
> test to fail.  The program works ok with static linkage.
> 
> It looks like the symbol search procedure used in glibc needs some work.

ok, recently events have prompted me to look at this again...

isn't the test itself broken?

it does this:

void *operator new(size_t sz) .....

int main() 
{
  A *bb = new A[10]; 
  ...
}

you define "operator new", but are calling operator new[], so it
defaults to the one in libstdc++...

if you change the definition of "operator new" to "operator new[]" then
the test will pass.

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] dynamic loader problem

[Thibaut VARENE]

Le mardi 12 mars 2002, =E0 05:46 , Randolph Chung a =E9crit :

>> Has anybody worked on the various "dl-" routines in =
glibc/sysdeps/hppa
>> recently?  That's probably where the dynamic loader problem lies.
>
> afaik ESIEE guys are looking at glibc.... thibaut? clement? any=20
> comments?
>
Well we're actually trying to rewrite the dynamic symbol resolver=20
following the ia64 model -- this should result in a significant speedup.=20=

(according to ACM)

We're currently focusing on the last point, so if we succeed, it might=20=

solve the problem (assuming it works fine on ia64).

We will keep the m-l informed of the progress of our work...


Thibaut VARENE
PA/Linux ESIEE Team
http://www.esiee.fr/puffin