Re: [parisc-linux] new toolchain (binutils 2.15, gcc 3.5, glibc 2.3.3) progress

Re: [parisc-linux] new toolchain (binutils 2.15, gcc 3.5, glibc 2.3.3) progress

[Joel Soete]

Carlos O'Donell wrote:
>>I can now reproduce what happend during check :)
>>and the crash occurs now at 0x401f67a8
>>
>>and ddd offers me a related dump window:
>>Dump of assembler code from 0x401f67a8 to 0x401f68a8:
>>    0x401f67a8:     ldw 0(,r25),r21
>>    0x401f67ac:     ldo 1115(r20),r20
> 
> 
> Joel, the most important code is what came *before* teh crash insn, you
> usually want atleast 16-32 insns before the crash to see what was going
> on, usually I trace back to try find the start of the function.
> 
> 
>>0002c77c <_nl_intern_locale_data>:
>>   2c77c:       6b c2 3f d9     stw rp,-14(,sp)
>>   2c780:       6f c6 00 80     stw,ma r6,40(,sp)
>>   2c784:       08 1a 02 46     copy r26,r6
>>   2c788:       6b c5 3f 89     stw r5,-3c(,sp)
>>   2c78c:       08 19 02 45     copy r25,r5
>>   2c790:       6b c3 3f 99     stw r3,-34(,sp)
>>   2c794:       08 18 02 43     copy r24,r3
>>   2c798:       6b c4 3f 91     stw r4,-38(,sp)
>>   2c79c:       8f 0e 81 d0     cmpib,>>= 7,r24,2c88c <_nl_intern_locale_data+0x110>
>>   2c7a0:       6b d3 3f c1     stw r19,-20(,sp)
>>   2c7a4:       22 98 04 00     ldil 20030000,r20
>>==>2c7a8:       0f 20 10 95     ldw 0(,r25),r21
> 
> 
> You are trying to get data from a pointer passed in as the second
> parameter to the function, you want to see the value of r25 before the
> load to see if it is valid. In gdb you can print register values or just
> use the info command to see all the regs. You can display regs by using
> '$r25' AFAIR, though the format may vary.
> 
ah I see
And btw if I put a break at 0x401f677c (corresponding to line 2c77c: the first routine insn), I would also be able to find the 
address from where it's called (just have to find back the right register).
Thanks for the tips.

> 
>>(gdb) break set_dp (if i well understand?)
> 
> 
> Yes, that's *very* early on. I try to break the startup in fixup().
> 
ok I will do so ;)

> 
>>and the prgm stop well at the requested address but unforunately bt still
>>refuse to unwind :(
> 
> 
> You won't get *any* usefull unwind info from debugging the loader, it's
> all very difficult during the early relocation process because the
> debugger doesn't understand what is being loaded where.
>  
Ok
> 
>>It seems so that the libc itself doesn't hown enough info for unwind. Is
>>-g option is enough or is there another configure option I missed or is
>>it possible to abuse a bit makefile files to force the libc build with more
>>usable info?
> 
> 
> There are tricks to debug programs that use the new loader, but if the
> loader is dying then there isn't much you can do except hack at from
> assembly.
> 
In fact I don't expect very much from assembly but hope more from gdb tracing back the way of process.
(I don't have any background about any loader so have all to learn :)

Thanks for advises,
	Joel
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] new toolchain (binutils 2.15, gcc 3.5, glibc 2.3.3) progress

[Joel Soete]

Carlos,

SOme news (but didn't help me :(

> -- Original Message --
> Date: Sat, 03 Jul 2004 12:01:18 +0000
> From: Joel Soete <soete.joel@tiscali.be>
> To: Carlos O'Donell <carlos@baldric.uwo.ca>
> Cc: parisc-linux@parisc-linux.org
> Subject: Re: [parisc-linux] new toolchain (binutils 2.15, gcc 3.5, glib=
c
> 2.3.3)
> 	progress
> 
> 
> 
> 
> Carlos O'Donell wrote:
> >>I can now reproduce what happend during check :)
> >>and the crash occurs now at 0x401f67a8
> >>
> >>and ddd offers me a related dump window:
> >>Dump of assembler code from 0x401f67a8 to 0x401f68a8:
> >>    0x401f67a8:     ldw 0(,r25),r21
> >>    0x401f67ac:     ldo 1115(r20),r20
> > 
> > 
> > Joel, the most important code is what came *before* teh crash insn,
you
> > usually want atleast 16-32 insns before the crash to see what was goi=
ng
> > on, usually I trace back to try find the start of the function.
> > 
> > 
> >>0002c77c <_nl_intern_locale_data>:
> >>   2c77c:       6b c2 3f d9     stw rp,-14(,sp)
> >>   2c780:       6f c6 00 80     stw,ma r6,40(,sp)
> >>   2c784:       08 1a 02 46     copy r26,r6
> >>   2c788:       6b c5 3f 89     stw r5,-3c(,sp)
> >>   2c78c:       08 19 02 45     copy r25,r5
> >>   2c790:       6b c3 3f 99     stw r3,-34(,sp)
> >>   2c794:       08 18 02 43     copy r24,r3
> >>   2c798:       6b c4 3f 91     stw r4,-38(,sp)
> >>   2c79c:       8f 0e 81 d0     cmpib,>>=3D 7,r24,2c88c <_nl_intern_l=
ocale_data+0x110>
> >>   2c7a0:       6b d3 3f c1     stw r19,-20(,sp)
> >>   2c7a4:       22 98 04 00     ldil 20030000,r20
> >>=3D=3D>2c7a8:       0f 20 10 95     ldw 0(,r25),r21
> > 
for a run i got r25=3D=3D0x4004b000

and the corresponding mapping at this moment is:
00010000-00011000 r-xp 00000000 08:0b 142497     /Develop/parisc-linux/bu=
ild/glibc/localedata/tst-leaks
00020000-00021000 rwxp 00000000 08:0b 142497     /Develop/parisc-linux/bu=
ild/glibc/localedata/tst-leaks
40000000-40004000 rw-p 40000000 00:00 0 
4004b000-4004c000 r--p 00000000 08:0b 2632       /Develop/parisc-linux/bu=
ild/glibc/localedata/de_DE.ISO-8859-1/LC_IDENTIFICATION
403eb000-40529000 r-xp 00000000 08:0b 18692      /Develop/parisc-linux/bu=
ild/glibc/libc.so
40529000-40536000 rwxp 0012e000 08:0b 18692      /Develop/parisc-linux/bu=
ild/glibc/libc.so
40536000-40538000 rwxp 40536000 00:00 0 
410bd000-410d4000 r-xp 00000000 08:0b 196300     /Develop/parisc-linux/bu=
ild/glibc/elf/ld.so
410e3000-410e7000 rwxp 00016000 08:0b 196300     /Develop/parisc-linux/bu=
ild/glibc/elf/ld.so
410e7000-41108000 rwxp 410e7000 00:00 0 
bff00000-bff02000 rwxp bff00000 00:00 0 

I try to compare with glibc build with gcc-3.3.4 (that takes me some time=

to remember That I have also to upgrade my kernel to make gdb stop at a
break point :( ) and I got the same matching r25 =3D=3D map address of /D=
evelop/parisc-linux/build/glibc/localedata/de_DE.ISO-8859-1/LC_IDENTIFICA=
TION.
But with gcc-3.3.4 that can continue not with gcc-3.5????

What do I miss?

> > 
> > You are trying to get data from a pointer passed in as the second
> > parameter to the function, you want to see the value of r25 before th=
e
> > load to see if it is valid. In gdb you can print register values or
just
> > use the info command to see all the regs. You can display regs by usi=
ng
> > '$r25' AFAIR, though the format may vary.
> > 
> ah I see
> And btw if I put a break at 0x401f677c (corresponding to line 2c77c: th=
e
> first routine insn), I would also be able to find the 
> address from where it's called (just have to find back the right regist=
er).

umm, at this place 'info reg' gave me (among other stuff :) )
rp             0x404179f3
r31            0x404179d7

(rp=3D=3Dr2 if i well understand)

do you remember what is the right calling adress?

Thanks again,
    Joel


-------------------------------------------------------------------------=
--
Tiscali ADSL LIGHT, 19,95 EUR/mois pendant 6 mois, c'est le moment de fai=
re
le pas!
http://reg.tiscali.be/default.asp?lg=3Dfr




_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] new toolchain (binutils 2.15, gcc 3.5, glibc 2.3.3) progress

[Joel Soete]

Hello Carlos,

Sorry for late answer, but I take some hollidays with my wife :)

Carlos O'Donell wrote:
> On Wed, Jul 07, 2004 at 07:02:37PM +0200, Joel Soete wrote:
> 
[...]

>>>>
>>for a run i got r25==0x4004b000
>>
>>and the corresponding mapping at this moment is:
>>00010000-00011000 r-xp 00000000 08:0b 142497     /Develop/parisc-linux/build/glibc/localedata/tst-leaks
>>00020000-00021000 rwxp 00000000 08:0b 142497     /Develop/parisc-linux/build/glibc/localedata/tst-leaks
>>40000000-40004000 rw-p 40000000 00:00 0
>>4004b000-4004c000 r--p 00000000 08:0b 2632       /Develop/parisc-linux/build/glibc/localedata/de_DE.ISO-8859-1/LC_IDENTIFICATION
>>403eb000-40529000 r-xp 00000000 08:0b 18692      /Develop/parisc-linux/build/glibc/libc.so
>>40529000-40536000 rwxp 0012e000 08:0b 18692      /Develop/parisc-linux/build/glibc/libc.so
>>40536000-40538000 rwxp 40536000 00:00 0
>>410bd000-410d4000 r-xp 00000000 08:0b 196300     /Develop/parisc-linux/build/glibc/elf/ld.so
>>410e3000-410e7000 rwxp 00016000 08:0b 196300     /Develop/parisc-linux/build/glibc/elf/ld.so
>>410e7000-41108000 rwxp 410e7000 00:00 0
>>bff00000-bff02000 rwxp bff00000 00:00 0
> 
> 
> That seems reasonable, it's trying to load the first word from the
> locale data. Not sure why that would crash. Is it still crashing in the
> same place?

Yes it always crashed at the same place.
That is why I would like to back traced the calling function to see if some space register is not broken?

>  
> 
>>I try to compare with glibc build with gcc-3.3.4 (that takes me some time
>>to remember That I have also to upgrade my kernel to make gdb stop at a
>>break point :( ) and I got the same matching r25 == map address of 
>>/Develop/parisc-linux/build/glibc/localedata/de_DE.ISO-8859-1/LC_IDENTIFICATION.
>>But with gcc-3.3.4 that can continue not with gcc-3.5????
> 
> 
> You have to get near that insn sequence and then start doing a binary
> stepping, usually like "si 1000" or something and then if you crash
> restart the process and keep going. You need to determine why the
> sequence would crash. Currently it looks like it shouldn't, which means
> we are probably looking at the wrong insns.
> 
> 
>>What do I miss?
> 
> 
> We are probably looking at the wrong insns.
> 
> c.
> 
> 
Well, ok it should be that gdb didn't show me the right stuff and so the only way I foreseen in this case is to introduce some 
printf (if posible, but iirc it's not) from place to place?

I will so continue.

Thanks for help,
	Joel
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] new toolchain (binutils 2.15, gcc 3.5, glibc 2.3.3) progress

[Carlos O'Donell]

On Mon, Jul 12, 2004 at 11:14:41AM +0000, Joel Soete wrote:
> >That seems reasonable, it's trying to load the first word from the
> >locale data. Not sure why that would crash. Is it still crashing in the
> >same place?
> 
> Yes it always crashed at the same place.
> That is why I would like to back traced the calling function to see if some 
> space register is not broken?

I don't currently have time to investigate, but believe me, it's not the
right place.

I recommend doing the following:

a. Start gdb, and specify you want to debug your new loader
        gdb "/yoursource/glibc-build/elf/ld.so.1"

b. Do the right 'set env' and the right 'set args'

c. Break at 'fixup' or 'rtld'

d. Then use 'si' to move forward slowly, it's best if you break on fixup
   because you can 'c' from fixup for a couple of times before you jump
   into the relocated executable.

e. Continue with 'si XXXX' to jump forward until it crashes, repeat
   again with binary steps. This process can be automated, and it's what
   I do when I don't trust the debugger.

In the end you should clearly see where you are dying! Though you might
have to do some assembly correlation to find the position
(/proc/self/maps is usefull at this point).

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux