[randolph@tausq.org: [parisc-linux] glibc update]

[randolph@tausq.org: [parisc-linux] glibc update]

[Carlos O'Donell Jr.]

R,

>1. the glibc i uploaded is actually built with a fairly old binutils
>(version 2.11.90.0.7-2.0.1). There could well be many binutils bug fixes 
>since then, but at least for this case it lets us build glibc without 
>the segfaults we see with the newer binutils

I'll see about giving it a try on my 712/60 and 715/50's

>2. the newest binutils (2.11.92.0.5-3), also in incoming, doesn't appear
>to address the glibc build issue as i originally thought. we still get
>ld.so segfaults as Carlos has observed earlier. Perhaps someone (Carlos,
>Alan, Rob?) can look at the binutils changes since then can see what
>broke?

Eventually I'll get that assembly trace done.

>3. with the glibc build (using old binutils) some of the linuxthreads
>tests are failing. in particular there's one case where it seems to get
>into a deadlock. i left it running overnight and it's still stuck ... 
>i don't know if this has always been broken though.

This reminds me, in general I keep forgetting to add the location of
/xxx/glibc-2.2.4/hppa-linux/obj to LD_LIBRARY_PATH. This nips some of
the tests in the bud since ld goes looking for the wrong library.

>Build logs for #3 and #2 above can be found at:
>#3: http://people.debian.org/~tausq/glibc.build.log2
>#2: http://people.debian.org/~tausq/glibc.build.log5

Have you tried running the tests by hand and seeing what the output is?

What is the output of running:
/home/randolph/gcc-3.0/glibc-2.2.4/hppa-linux/obj/math/test-fenv.out

c.

Re: [randolph@tausq.org: [parisc-linux] glibc update]

[Randolph Chung]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1163 bytes --]

> >#3: http://people.debian.org/~tausq/glibc.build.log2
> >#2: http://people.debian.org/~tausq/glibc.build.log5
> 
> Have you tried running the tests by hand and seeing what the output is?
> What is the output of running:
> /home/randolph/gcc-3.0/glibc-2.2.4/hppa-linux/obj/math/test-fenv.out

eh? that's the output report file :)

i get a floating point exception when running the corresponding
executable.


Program received signal SIGFPE, Arithmetic exception.
0x4011b328 in vfprintf () from /lib/libc.so.6
(gdb) bt
#0  0x4011b328 in vfprintf () from /lib/libc.so.6
#1  0x40123490 in printf () from /lib/libc.so.6
#2  0x00010f8c in feenv_mask_test (
    flag_name=0x40210048 "@\036\177P@\036\177T@\036\177`@\036\177X@\036\177h@\036\177\220@\036\177Ð@\036\177Ô@\036\177Ø@\036\177à@\036\177è@\036\177ø@\036\177ð@\036\200", fe_exc=1) at test-fenv.c:332
#3  0x0001160c in fe_single_test (flag_name=0x11f98 "FE_INEXACT", fe_exc=1)
    at test-fenv.c:607
#4  0x00011664 in feenv_tests () at test-fenv.c:625
#5  0x000116e4 in main () at test-fenv.c:654


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

Re: [randolph@tausq.org: [parisc-linux] glibc update]

[Carlos O'Donell Jr.]

> 
> eh? that's the output report file :)
> 
> i get a floating point exception when running the corresponding
> executable.
> 
> 
> Program received signal SIGFPE, Arithmetic exception.
> 0x4011b328 in vfprintf () from /lib/libc.so.6
> (gdb) bt
> #0  0x4011b328 in vfprintf () from /lib/libc.so.6
> #1  0x40123490 in printf () from /lib/libc.so.6
> #2  0x00010f8c in feenv_mask_test (
>     flag_name=0x40210048 "@\036\177P@\036\177T@\036\177`@\036\177X@\036\177h@\036\177\220@\036\177Ð@\036\177Ô@\036\177Ø@\036\177à@\036\177è@\036\177ø@\036\177ð@\036\200", fe_exc=1) at test-fenv.c:332
> #3  0x0001160c in fe_single_test (flag_name=0x11f98 "FE_INEXACT", fe_exc=1)
>     at test-fenv.c:607
> #4  0x00011664 in feenv_tests () at test-fenv.c:625
> #5  0x000116e4 in main () at test-fenv.c:654
> 
>

When running these tests, it gets a little complex.
I'm pretty sure the test needs to be run against the
libc.so.6 that you are building, and not the one in /lib
on your system.

You could set the LD_LIBRARY_PATH to the location of the
objects you are building and then run it...

However, if you do that, then gdb might act strangely
with this newly built libc (since ld trying to load gdb
will use the libc in the library path).

How do you load gdb with one libc and debug a program
that uses another?

When I run the test-fenv, I get a whole list of output
criteria, but it finally exist with $?=132
I'm running with LD_LIBRARY_PATH set to the new libc,
glibc 2.2.4-2, built with newer binutils.

c.

Re: [randolph@tausq.org: [parisc-linux] glibc update]

[Matthew Wilcox]

On Fri, Oct 19, 2001 at 01:17:19AM -0400, Carlos O'Donell Jr. wrote:
> You could set the LD_LIBRARY_PATH to the location of the
> objects you are building and then run it...
> 
> However, if you do that, then gdb might act strangely
> with this newly built libc (since ld trying to load gdb
> will use the libc in the library path).
> 
> How do you load gdb with one libc and debug a program
> that uses another?

run gdb, then type
set env LD_LIBRARY_PATH blah blah blah

-- 
Revolutions do not require corporate support.

Re: [randolph@tausq.org: [parisc-linux] glibc update]

[John David Anglin]

> How do you load gdb with one libc and debug a program
> that uses another?

Build a static version of gdb.

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