[parisc-linux] glibc 2.2.3: setjmp/longjmp

[parisc-linux] glibc 2.2.3: setjmp/longjmp

[Matthew Wilcox]

i think i've traced the problem down to setjmp/longjmp not working.

here's what happens:

__libc_dlsym calls
dlerror_run(do_dlsym) calls
_dl_catch_error -> setjmp, then calls
do_dlsym which calls
_dl_lookup_symbol which fails and calls
_dl_signal_cerror which calls
_dl_signal_error which calls longjmp

At this point, we should expect to get back to where we called setjmp, however that appears to not work.  If I add:

  errcode = setjmp (c.env);
_dl_printf("after setjmp, errcode = %u\n", errcode);
  if (__builtin_expect (errcode, 0) == 0)

the output from my debug logs looks like:

__libc_dlsym gconv_end
after setjmp, errcode = 0
current_value = 0 0
in the if... *ref = 0
in the if... not checking ELFW(ST_BIND)
in _dl_signal_cerror, receiver = 0
_dl_signal_error(0, /home/willy/cvs/glibc-build/iconvdata/SJIS.so, undefined symbol: gconv_end)
_dl_signal_error: lcatch = 7ff01300
_dl_signal_error: about to longjmp to 7ff01308
dlerror_run: errstr = (null)
Segmentation fault

so it's returning to the _caller_ of _dl_catch_error instead.  Ugh.
I'll be trying to decode assembler now...

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[John David Anglin]

> i think i've traced the problem down to setjmp/longjmp not working.

My first guess would be the pic offset table register is not being
restored in longjmps into PIC code.  This must be done either in the
receiver or just before the longjmp.  Of course, the longjmp can come
from non-PIC code.  I am just about to submit a patch to fix a similar
problem with gcc's builtin_setjmp/longjmp on the PA for the 3.0 branch.

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

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Matthew Wilcox]

On Fri, May 04, 2001 at 04:18:42PM -0400, John David Anglin wrote:
> My first guess would be the pic offset table register is not being
> restored in longjmps into PIC code.  This must be done either in the
> receiver or just before the longjmp.  Of course, the longjmp can come
> from non-PIC code.  I am just about to submit a patch to fix a similar
> problem with gcc's builtin_setjmp/longjmp on the PA for the 3.0 branch.

hmm.. longjmp() restores r3-r19, r27, r30, r2, then fr12-21.  should it
be restoring r29 too?  if so, no problem -- we don't need to save/restore
r19 anyway.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Matthew Wilcox]

On Fri, May 04, 2001 at 04:18:42PM -0400, John David Anglin wrote:
> > i think i've traced the problem down to setjmp/longjmp not working.
> 
> My first guess would be the pic offset table register is not being

Thinking about it some more, I don't see how this can be the case.  Here's
the assembly:

    ea18:       e8 42 11 c4     b,l 14300 <_setjmp>,rp
    ea1c:       6b dc 3c 91     stw ret0,-1b8(sr0,sp)
    ea20:       34 1a 00 02     ldi 1,r26
    ea24:       4b d3 3f 11     ldw -78(sr0,sp),r19
    ea28:       08 1c 02 43     copy ret0,r3
    ea2c:       08 03 02 58     copy r3,r24
    ea30:       2a 60 00 00     addil 0,r19,%r1
    ea34:       48 21 07 d0     ldw 3e8(sr0,r1),r1
    ea38:       e8 40 02 6c     b,l fb74 <_dl_dprintf>,rp

after calling longjmp, that _dl_dprintf doesn't get called.  I can't
explain that.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[John David Anglin]

> Thinking about it some more, I don't see how this can be the case.  Here's
> the assembly:
> 
>     ea18:       e8 42 11 c4     b,l 14300 <_setjmp>,rp
>     ea1c:       6b dc 3c 91     stw ret0,-1b8(sr0,sp)
>     ea20:       34 1a 00 02     ldi 1,r26
>     ea24:       4b d3 3f 11     ldw -78(sr0,sp),r19
>     ea28:       08 1c 02 43     copy ret0,r3
>     ea2c:       08 03 02 58     copy r3,r24
>     ea30:       2a 60 00 00     addil 0,r19,%r1
>     ea34:       48 21 07 d0     ldw 3e8(sr0,r1),r1
>     ea38:       e8 40 02 6c     b,l fb74 <_dl_dprintf>,rp
> 
> after calling longjmp, that _dl_dprintf doesn't get called.  I can't
> explain that.

Doesn't look like _setjmp comes back at all.  Put a break on ea18
and start stepping.  It might help to do a static link.

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

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Matthew Wilcox]

On Fri, May 04, 2001 at 05:31:30PM -0400, John David Anglin wrote:
> Doesn't look like _setjmp comes back at all.  Put a break on ea18
> and start stepping.  It might help to do a static link.

this code is in the dynamic linker :-))

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[John David Anglin]

> On Fri, May 04, 2001 at 05:31:30PM -0400, John David Anglin wrote:
> > Doesn't look like _setjmp comes back at all.  Put a break on ea18
> > and start stepping.  It might help to do a static link.
> 
> this code is in the dynamic linker :-))

Can you set a break on main, run to main, set the break in the
dynamic linker, then continue?

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

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Matthew Wilcox]

On Fri, May 04, 2001 at 05:51:59PM -0400, John David Anglin wrote:
> > On Fri, May 04, 2001 at 05:31:30PM -0400, John David Anglin wrote:
> > > Doesn't look like _setjmp comes back at all.  Put a break on ea18
> > > and start stepping.  It might help to do a static link.
> > 
> > this code is in the dynamic linker :-))
> 
> Can you set a break on main, run to main, set the break in the
> dynamic linker, then continue?

No, though this is probably due more to my lack of skill with gdb than
anything else.

I set a breakpoint on _dl_signal_error ok.
Then inspecting the jmpbuf indicates that it's returning to 4101434f

/proc/<pid>/maps indicates:
0000000041000000-000000004101a000 r-xp 0000000000000000 08:03 1754026    /home/willy/cvs/glibc-build/elf/ld.so

objdump --disassemble shows:

000143e0 <index>:
...
   143f4:       6b d3 3f c1     stw r19,-20(sr0,sp)

which is the middle of nowhere.  Actually, it's right _after_ __longjmp.
clearly it should be returning to 4100ea4c

Going back and setting a breakpoint on _dl_catch_error indicates that the
value being put at ((unsigned long *)c.env)[20] is 0x4101434F, so the jmpbuf
isn't being corrupted...

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[John David Anglin]

> which is the middle of nowhere.  Actually, it's right _after_ __longjmp.
> clearly it should be returning to 4100ea4c

In __longjmp.S, try changing `ldw     80(%r26), %rp' to `ldw     80(%r26), %r2'.Same in setjmp.S.  Possibly, rp is not defined.  This cause the above.

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

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Matthew Wilcox]

taking a somewhat different approach:

    ea44:       e8 42 11 d4     b,l 14334 <_setjmp>,rp

00014334 <_setjmp>:
   14334:       6b c2 3f d9     stw rp,-14(sr0,sp)
   14338:       34 19 00 00     ldi 0,r25
   1433c:       37 de 00 80     ldo 40(sp),sp
   14340:       6b d3 3f c1     stw r19,-20(sr0,sp)
   14344:       e8 41 00 d8     b,l 163b8 <__sigsetjmp>,rp
   14348:       6b d3 3f 91     stw r19,-38(sr0,sp)
   1434c:       4b d3 3f 91     ldw -38(sr0,sp),r19
   14350:       4b c2 3f 59     ldw -54(sr0,sp),rp
   14354:       e8 40 c0 00     bv r0(rp)
   14358:       37 de 3f 81     ldo -40(sp),sp

000163b8 <__sigsetjmp>:
   163b8:       0f 43 12 80     stw  r3,0(sr0,r26)
   163bc:       0f 44 12 90     stw  r4,8(sr0,r26)
   163c0:       0f 45 12 98     stw  r5,c(sr0,r26)
   163c4:       6b 46 00 20     stw r6,10(sr0,r26)
   163c8:       6b 47 00 28     stw r7,14(sr0,r26)
   163cc:       6b 48 00 30     stw r8,18(sr0,r26)
   163d0:       6b 49 00 38     stw r9,1c(sr0,r26)
   163d4:       6b 4a 00 40     stw r10,20(sr0,r26)
   163d8:       6b 4b 00 48     stw r11,24(sr0,r26)
   163dc:       6b 4c 00 50     stw r12,28(sr0,r26)
   163e0:       6b 4d 00 58     stw r13,2c(sr0,r26)
   163e4:       6b 4e 00 60     stw r14,30(sr0,r26)
   163e8:       6b 4f 00 68     stw r15,34(sr0,r26)
   163ec:       6b 50 00 70     stw r16,38(sr0,r26)
   163f0:       6b 51 00 78     stw r17,3c(sr0,r26)
   163f4:       6b 52 00 80     stw r18,40(sr0,r26)
   163f8:       6b 53 00 88     stw r19,44(sr0,r26)
   163fc:       6b 5b 00 90     stw dp,48(sr0,r26)
   16400:       6b 5e 00 98     stw sp,4c(sr0,r26)
   16404:       6b 42 00 a0     stw rp,50(sr0,r26)
   16408:       37 53 00 b0     ldo 58(r26),r19
   1640c:       2e 70 12 2c     fstd,ma  fr12,8(sr0,r19)
   16410:       2e 70 12 2d     fstd,ma  fr13,8(sr0,r19)
   16414:       2e 70 12 2e     fstd,ma  fr14,8(sr0,r19)
   16418:       2e 70 12 2f     fstd,ma  fr15,8(sr0,r19)
   1641c:       2e 70 12 30     fstd,ma  fr16,8(sr0,r19)
   16420:       2e 70 12 31     fstd,ma  fr17,8(sr0,r19)
   16424:       2e 70 12 32     fstd,ma  fr18,8(sr0,r19)
   16428:       2e 70 12 33     fstd,ma  fr19,8(sr0,r19)
   1642c:       2e 70 12 34     fstd,ma  fr20,8(sr0,r19)
   16430:       2e 60 12 15     fstd  fr21,0(sr0,r19)
   16434:       e8 1e 0a d5     b,l 139a4 <__sigjmp_save>,r0
   16438:       08 00 02 40     nop

000139a4 <__sigjmp_save>:
   139a4:       6b 40 01 50     stw r0,a8(sr0,r26)
   139a8:       e8 40 c0 00     bv r0(rp)
   139ac:       34 1c 00 00     ldi 0,ret0

oh.  wait.  1434F is exactly where it should be.  *sigh*.  So why the hell
is it returning to the wrong place?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Matthew Wilcox]

On Fri, May 04, 2001 at 11:57:11PM +0100, Matthew Wilcox wrote:
> 
> taking a somewhat different approach:
> 
>     ea44:       e8 42 11 d4     b,l 14334 <_setjmp>,rp
> 
> 00014334 <_setjmp>:
>    14334:       6b c2 3f d9     stw rp,-14(sr0,sp)
>    14338:       34 19 00 00     ldi 0,r25
>    1433c:       37 de 00 80     ldo 40(sp),sp
>    14340:       6b d3 3f c1     stw r19,-20(sr0,sp)
>    14344:       e8 41 00 d8     b,l 163b8 <__sigsetjmp>,rp
>    14348:       6b d3 3f 91     stw r19,-38(sr0,sp)
>    1434c:       4b d3 3f 91     ldw -38(sr0,sp),r19
>    14350:       4b c2 3f 59     ldw -54(sr0,sp),rp
>    14354:       e8 40 c0 00     bv r0(rp)
>    14358:       37 de 3f 81     ldo -40(sp),sp

> oh.  wait.  1434F is exactly where it should be.  *sigh*.  So why the hell
> is it returning to the wrong place?

OK, got it.  the first time we call _setjmp, everything is fine.
But when we return to it through longjmp, the `rp' which got stored has
changed, and now its the rp for the last function we called.  Which is
what happens using `step' through gdb (now that i have a working gdb,
thanks for the deb, matt).

Ugh.  I guess we can't use _setjmp then, at least in its current form.
Oh well, at least the problem's found.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Alan Modra]

On Sat, 5 May 2001, Matthew Wilcox wrote:

> OK, got it.  the first time we call _setjmp, everything is fine.
> But when we return to it through longjmp, the `rp' which got stored has
> changed, and now its the rp for the last function we called.

Oh horrible.  Yes, the stack frame that sysdeps/generic/bsd-_setjmp.c is
using to load rp is no longer valid.  Oh well, the comment in
generic/bsd-_setjmp.c should have warned us, which leads to another
question.  Why was this added to gcc/config/pa/pa-linux.h?

/* Sibcalls, stubs, and elf sections don't play well.  */
#undef FUNCTION_OK_FOR_SIBCALL
#define FUNCTION_OK_FOR_SIBCALL(x) 0

Seems a bit drastic to me.  The correspnding define in pa.h should be OK
for us.

-- 
Alan Modra

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Matthew Wilcox]

On Sat, May 05, 2001 at 10:19:05AM +0930, Alan Modra wrote:
> Oh horrible.  Yes, the stack frame that sysdeps/generic/bsd-_setjmp.c is
> using to load rp is no longer valid.  Oh well, the comment in
> generic/bsd-_setjmp.c should have warned us,

sure, if we'd ever looked in there :-)

on this subject, there've now been three things (LFS, ELF_OSABI_LINUX
and setjmp) which people have said `oh yeah, thought we might have some
problems with those, someone mentioned that' (or similar) once the problem
was found.  would anyone care to remember anything else that they thought
`might be a problem at some point'?

> which leads to another
> question.  Why was this added to gcc/config/pa/pa-linux.h?
> 
> /* Sibcalls, stubs, and elf sections don't play well.  */
> #undef FUNCTION_OK_FOR_SIBCALL
> #define FUNCTION_OK_FOR_SIBCALL(x) 0
> 
> Seems a bit drastic to me.  The correspnding define in pa.h should be OK
> for us.

I vaguely remember that.  Searching the list archive finds:
http://lists.parisc-linux.org/pipermail/parisc-linux/2000-July/009002.html

so it's dhd's fault :-)

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Alan Modra]

On Sat, 5 May 2001, Matthew Wilcox wrote:

> was found.  would anyone care to remember anything else that they thought
> `might be a problem at some point'?

lock alignment => malloc alignment.  (Possibly already fixed with new
glibc. I haven't checked.)

[re: FUNCTION_OK_FOR_SYSCALL == 0]
> I vaguely remember that.  Searching the list archive finds:
> http://lists.parisc-linux.org/pipermail/parisc-linux/2000-July/009002.html

That patch seems to be a merge, so we don't have the real reason for
the change.

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Matthew Wilcox]

On Sat, May 05, 2001 at 10:48:14AM +0930, Alan Modra wrote:
> On Sat, 5 May 2001, Matthew Wilcox wrote:
> 
> > was found.  would anyone care to remember anything else that they thought
> > `might be a problem at some point'?
> 
> lock alignment => malloc alignment.  (Possibly already fixed with new
> glibc. I haven't checked.)

Yup, that got taken care of by Ulrich.

> [re: FUNCTION_OK_FOR_SYSCALL == 0]
> > I vaguely remember that.  Searching the list archive finds:
> > http://lists.parisc-linux.org/pipermail/parisc-linux/2000-July/009002.html
> 
> That patch seems to be a merge, so we don't have the real reason for
> the change.

Sure, but I'm not sure we had it before that.  Wait!  We have cvs history!
http://puffin.external.hp.com/cvs/gcc/gcc/config/pa/pa-linux.h?r1=1.1&r2=1.2
Oh.  The comment isn't helpful.  I guess you'll have to ask dhd...
dhd@debian.org is one of his valid addresses.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Ulrich Drepper]

Matthew Wilcox <matthew@wil.cx> writes:

> On Fri, May 04, 2001 at 05:31:30PM -0400, John David Anglin wrote:
> > Doesn't look like _setjmp comes back at all.  Put a break on ea18
> > and start stepping.  It might help to do a static link.
> 
> this code is in the dynamic linker :-))

And the problem is?  I debug ld.so as a normal program.  The necessary
patches I came up with are in the official gdb for quite some time
now.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Grant Grundler]

Ulrich Drepper wrote:
> Matthew Wilcox <matthew@wil.cx> writes:
> > On Fri, May 04, 2001 at 05:31:30PM -0400, John David Anglin wrote:
> > > ....  It might help to do a static link.
> > 
> > this code is in the dynamic linker :-))
> 
> And the problem is?  I debug ld.so as a normal program.  The necessary
> patches I came up with are in the official gdb for quite some time
> now.

Seems Matthew misunderstood the suggestion to use a static link.
I also read jda's comment to mean statically link the target obj.
It's clear now jda meant gdb.

grant

Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[John David Anglin]

> Seems Matthew misunderstood the suggestion to use a static link.
> I also read jda's comment to mean statically link the target obj.
> It's clear now jda meant gdb.

The first was my original intent.  However, I also find gdb doesn't
crash as much when it is statically linked.

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

Re: [parisc-linux] glibc 2.2.3: setjmp/longjmp

[Matthew Wilcox]

On Sat, May 05, 2001 at 11:14:55PM -0700, Ulrich Drepper wrote:
> Matthew Wilcox <matthew@wil.cx> writes:
> 
> > On Fri, May 04, 2001 at 05:31:30PM -0400, John David Anglin wrote:
> > > Doesn't look like _setjmp comes back at all.  Put a break on ea18
> > > and start stepping.  It might help to do a static link.
> > 
> > this code is in the dynamic linker :-))
> 
> And the problem is?  I debug ld.so as a normal program.  The necessary
> patches I came up with are in the official gdb for quite some time
> now.

ok, here's a gdb session from yesterday.  i'm trying to find out why
dlfcn/tst-dladdr is failing.

here's my .gdbinit:

set env GCONV_PATH=/home/willy/cvs/glibc-B/iconvdata
set env LC_ALL=C
file /home/willy/cvs/glibc-B/elf/ld.so.1
set args --library-path /home/willy/cvs/glibc-B:/home/willy/cvs/glibc-B/math:/home/willy/cvs/glibc-B/elf:/home/willy/cvs/glibc-B/dlfcn:/home/willy/cvs/glibc-B/nss:/home/willy/cvs/glibc-B/nis:/home/willy/cvs/glibc-B/rt:/home/willy/cvs/glibc-B/resolv:/home/willy/cvs/glibc-B/crypt:/home/willy/cvs/glibc-B/linuxthreads /home/willy/cvs/glibc-B/dlfcn/tst-dladdr --direct
break _dl_init
run
add-symbol-file /home/willy/cvs/glibc-B/dlfcn/tst-dladdr 0x010000
add-symbol-file /home/willy/cvs/glibc-B/dlfcn/libdl.so 0x40001000
add-symbol-file /home/willy/cvs/glibc-B/libc.so 0x040014000

start gdb, check the /proc/<pid>/maps file:

0000000000010000-0000000000012000 r-xp 0000000000000000 08:03 279751     /home/willy/cvs/glibc-B/dlfcn/tst-dladdr
0000000040001000-0000000040004000 r-xp 0000000000000000 08:03 279740     /home/willy/cvs/glibc-B/dlfcn/libdl.so
0000000040014000-0000000040141000 r-xp 0000000000000000 08:03 639967     /home/willy/cvs/glibc-B/libc.so
0000000041000000-000000004101a000 r-xp 0000000000000000 08:03 1327771    /home/willy/cvs/glibc-B/elf/ld.so

so all seems well.

here's the output from gdb:

This GDB was configured as "hppa2.0-unknown-linux-gnu".
Breakpoint 1 at 0xebe8: file dl-init.c, line 98.
Breakpoint 1 at 0x4100ebe8: file dl-init.c, line 98.

Breakpoint 1, _dl_init (main_map=0x84690, argc=545552, argv=0x86210, env=0x0)
    at dl-init.c:98
98        if (__builtin_expect (_dl_initfirst != NULL, 0))
add symbol table from file "/home/willy/cvs/glibc-B/dlfcn/tst-dladdr" at
        .text_addr = 0x10000
add symbol table from file "/home/willy/cvs/glibc-B/dlfcn/libdl.so" at
        .text_addr = 0x40001000
add symbol table from file "/home/willy/cvs/glibc-B/libc.so" at
        .text_addr = 0x40014000
(gdb) break main 
Breakpoint 2 at 0x10614: file ../test-skeleton.c, line 123.
(gdb) c
Continuing.

Breakpoint 1, _dl_init (main_map=0x3, argc=-2147483646, argv=0x0, 
    env=0x40157ebc) at dl-init.c:98
98        if (__builtin_expect (_dl_initfirst != NULL, 0))
(gdb) c
Continuing.
/home/willy/cvs/glibc-B/dlfcn/tst-dladdr: dladdr failed

Program exited with code 01.

so the program never stops at main().

-- 
Revolutions do not require corporate support.