Randolph Chung | 11 Mar 17:28

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

> The reason for the segmentation fault is the R_PARISC_IPLT isn't
> being handled correctly and the indirect call to the constructor
> for the library branches to the wrong location.

here's what i see....

__do_global_ctors_aux is trying to load a value from the GOT
(__CTORS_LIST i think). I'm seeing that it loads some garbage value
(0x4fd23f01 in my case), and then it tries to do a $dyncall on that.

__do_global_ctors_aux does something like:

addil 0(%r19),%r1
ldw 28(%r1),%ret0
ldw -4(%ret0),%r3
...
copy %r3,%r22
b,l $$dyncall, %r31

$r19+0x28 is 0x41896830; points inside the .plt. seems reasonable

but *(%ret0-4) points inside the text section, so r22 eventually gets 
loaded with an instruction value (0x4fd23f01 == ldw,mb -80(sp),r18)

dunno if this helps with anything... have to think about it somemore to 
see what's happening...

randolph

(Continue reading)

John David Anglin | 12 Mar 03:10
Picon

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

> but *(%ret0-4) points inside the text section, so r22 eventually gets 
> loaded with an instruction value (0x4fd23f01 == ldw,mb -80(sp),r18)

r22 should be pointing to a function descriptor and have the plabel
bit set.  It's a relative rare situation when an indirect call can
be made directly (no shared libraries).

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)


Gmane