[parisc-linux] Re: python (toolchain really) problems

Alan Modra amodra@bigpond.net.au
Sat, 27 Oct 2001 10:48:24 +0930


On Fri, Oct 26, 2001 at 04:19:17PM -0600, Paul Bame wrote:
> 
> One good reason not to upgrade right now is python is broken, but I'm
> pretty sure this is a dynamic linker bug.  I tried my test against
> glibc 2.2.4-4 which is currently in incoming.
> 
> _start is making it's first function call:
> 
> 0x1053c <_start+40>:    ldil 20800,dp
> 0x10540 <_start+44>:    ldo 8(dp),dp
> 0x10544 <_start+48>:    b,l 0x104d4 <_init+56>,rp
> 
> to here:
> 
> 000104d4 <.text>:
>    104d4:       2b 60 00 00     addil 0,dp,%r1
>    104d8:       48 35 02 58     ldw 12c(sr0,r1),r21
>    104dc:       ea a0 c0 00     bv r0(r21)
>    104e0:       48 33 02 60     ldw 130(sr0,r1),r19

I agree that it looks like a dynamic linker problem.  For those who might
be confused about how the above stub can lead to an IAOQ of 0x00c0ffee
with r21 = 0xdeadbeef, the explanation is that a little more code has
run than Paul showed.  The address stored at 0x20800+0x12c is that of
the lazy linking .plt stub, which looks like

1: ldw	0(%r20),%r22
   bv	%r0(%r22)
   ldw	4(%r20),%r21
start_here:
   b,l	1b,%r20
   depi	0,31,2,%r20
  .word	fixup_func	initialised to 0x00c0ffee by the linker
  .word	fixup_ltp	initialised to 0xdeadbeef

so for some reason the dynamic linker has failed to replace the fixup_func
dummy value with the real value.  See glibc/sysdeps/hppa/dl_machine.h:
elf_machine_runtime_setup for where this is supposed to happen.  From
the symptoms that Paul has shown here, I'd guess that DT_JMPREL or
DT_PLTRELSZ are missing/zero in Paul's binary, or that for some other
reason, elf_machine_runtime_setup hasn't even been called.

BTW, I don't think lazy linking has ever been tested because dl-machine.h
failed to define ELF_MACHINE_PLTREL_OVERLAP.  This had the unfortunate
effect of always fully relocating .plt.

Anyway, I hope the above explanation is enough for someone to track down
the problem if I don't find time.

Alan

> r21 contains '0xdeadbeef' -- here are the details:
> 
> do_page_fault() pid=16052 command='python2' type=6 address=0x00c0ffef
> vm_start = 0x00020000, vm_end = 0x00021000
> 
>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001101111111100001111
> r0-3     0000000000000000 0000000000020808 000000000001054f 0000000040029abc
> r4-7     000000004024d048 00000000000bfef0 00000000000bfc30 00000000000bfc30
> r8-11    00000000ffffffff 00000000000b9010 00000000000bfd70 00000000000bfcb0
> r12-15   0000000000000000 00000000ffffffff 00000000000bfcf0 0000000000000000
> r16-19   0000000000000000 0000000000000004 0000000000000004 0000000000020808
> r20-23   0000000000020958 00000000deadbeef 0000000000c0ffee 000000000002090e
> r24-27   00000000bff003b8 0000000000000001 0000000000020916 0000000000020808
> r28-31   0000000000000000 000000007efefeff 00000000bff00580 000000004000ddf7
> sr0-3    0000000000001c80 0000000000001c80 0000000000000000 0000000000001c80
> sr4-7    0000000000001c80 0000000000001c80 0000000000001c80 0000000000001c80
> 
> IASQ: 0000000000001c80 0000000000001c80 IAOQ: 0000000000c0ffef 0000000000c0fff3
>  IIR: 43ffff80    ISR: 0000000000001c80  IOR: 000000004033a08c
>  CPU:        0   CR30: 0000000013f24000 CR31: 0000000010450000
>  ORIG_R28: 00000000bff00b08