Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: rtld problem



christos%astron.com@localhost (Christos Zoulas) wrote:
>In article <x736ztwugb.fsf%ren.fdy2.co.uk@localhost>,
>Robert Swindells  <rjs%fdy2.co.uk@localhost> wrote:
>>
>>I wrote:
>>>Is anyone else getting core dumps when running dynamically linked
>>>programs ?
>>>
>>>An example backtrace for ifconfig is:
>>>
>>>#0  0x00007f7ff7c0b79f in memcpy () from /libexec/ld.elf_so
>>>#1  0x00007f7ff7c04302 in _rtld_do_copy_relocation
>>(dstobj=dstobj@entry=0x7f7ff7ef9000, rela=<optimized out>,
>>rela=<optimized out>) at /u1/src/libexec/ld.elf_so/reloc.c:105
>>>#2  0x00007f7ff7c04405 in _rtld_do_copy_relocations
>>(dstobj=0x7f7ff7ef9000) at /u1/src/libexec/ld.elf_so/reloc.c:147
>>>#3  0x00007f7ff7c03029 in _rtld (sp=<optimized out>,
>>relocbase=<optimized out>) at /u1/src/libexec/ld.elf_so/rtld.c:733
>>>#4  0x00007f7ff7c007a3 in .rtld_start () from /libexec/ld.elf_so
>>>#5  0x0000000000000000 in ?? ()
>>>
>>>This is with sources from today on amd64, including latest binutils.
>>>
>>>It looks as if the mapbase and relocbase members of the Obj_Entry struct
>>>are set to unmapped addresses.
>>
>>The symbol that is being processed at the time of the fault is
>>"_in6addr_any", which is a weak alias to "in6addr_any".
>>
>>In an older working copy of ifconfig it has:
>>
>>Disassembly of section .bss:
>>  
>>0000000000618300 <_in6addr_any>:
>>        ...
>>
>>The non-working latest copy has:
>>
>>Disassembly of section .data.rel.ro:
>>  
>>0000000000615e40 <_in6addr_any>:
>>        ...
>
>I am unable to reproduce this... What are the addresses is it faulting
>at?

This seems to be caused by differences in build options, I was building
with:

USE_SSP=no
USE_FORT=no
MKPIE=no

Without them I get:

Disassembly of section .got:

0000000000219fa8 <.got>:
        ...
                        219fc0: R_X86_64_GLOB_DAT       in6addr_any

Which is the same as in the latest snapshot on nyftp.

I think the faulting address is the destination of the memcpy(), it
doesn't look to be mapped writable.

Robert Swindells


Home | Main Index | Thread Index | Old Index