Re: entries in PT_DYNAMIC section refer to the correct address at runtime?
On Thu, Sep 14, 2017 at 12:09:51PM +0800, Yubin Ruan wrote:
> Hi,
>
> I read the ELF spec and note that, a segment designated by a program
> header of type PT_DYNAMIC have several entries, many of which contain
> addresses of other things. For example, an entry of type DT_SYMTAB was
> described (in the ELF) spec to "holds the address of the symbol
> table". I wonder whether this address is true at runtime?
>
> Normally a program header would have the following structure:
>
> typedef struct {
> Elf32_Word p_type;
> Elf32_Off p_offset;
> Elf32_Addr p_vaddr;
> Elf32_Addr p_paddr;
> Elf32_Word p_filesz;
> Elf32_Word p_memsz;
> Elf32_Word p_flags;
> Elf32_Word p_align;
> } Elf32_Phdr;
>
> The `p_vaddr` hold the virtual address (runtime address) for a shared
> object file and a executable file. But, as stated in the ELF spec,
> `p_vaddr` might not be correct for a shared object (because it is
> required to be PIC). So, if that `p_vaddr` is not correct, will those
> entries in PT_DYNAMIC be correct?
DT_ entries that specify addresses will need to be offset by the base
address.
--
Alan Modra
Australia Development Lab, IBM
[Bug tools/22138] New: Support marking "debug" info files with special ET_GNU_DEBUG_* values.
https://sourceware.org/bugzilla/show_bug.cgi?id=22138 Bug ID: 22138 Summary: Support marking "debug" info files with special ET_GNU_DEBUG_* values. Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: tools Assignee: unassigned at sourceware dot org Reporter: fweimer at redhat dot com CC: carlos at redhat dot com, elfutils-devel at sourceware dot org, fweimer at redhat dot com, unassigned at sourceware dot org Blocks: 22101 Target Milestone: --- +++ This bug was initially created as a clone of Bug #22136 +++ We need a way to identify "debug" info files, which appear like they are ELF files but if inspected are actually missing a lot of information and can't be properly parsed without the original DSO or executable. To that end I suggest we adopt: * ET_GNU_DEBUG_EXEC * ET_GNU_DEBUG_DYN * ET_GNU_DEBUG_REL As ways to mark these files a debug information files. We can place them into the OS-specific area, and audit that we don't overlap anything important from other OSs. We would need new binutils options to edit, adjust and set the "debug"-ness of files. Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=22101 [Bug 22101] Dynamic loader must ignore "debug" shared objects e.g. ET_GNU_DEBUG_* -- You are receiving this mail because: You are on the CC list for the bug.
Re: entries in PT_DYNAMIC section refer to the correct address at runtime?
2017-09-14 18:25 GMT+08:00 Alan Modra :
> On Thu, Sep 14, 2017 at 12:09:51PM +0800, Yubin Ruan wrote:
>> Hi,
>>
>> I read the ELF spec and note that, a segment designated by a program
>> header of type PT_DYNAMIC have several entries, many of which contain
>> addresses of other things. For example, an entry of type DT_SYMTAB was
>> described (in the ELF) spec to "holds the address of the symbol
>> table". I wonder whether this address is true at runtime?
>>
>> Normally a program header would have the following structure:
>>
>> typedef struct {
>> Elf32_Word p_type;
>> Elf32_Off p_offset;
>> Elf32_Addr p_vaddr;
>> Elf32_Addr p_paddr;
>> Elf32_Word p_filesz;
>> Elf32_Word p_memsz;
>> Elf32_Word p_flags;
>> Elf32_Word p_align;
>> } Elf32_Phdr;
>>
>> The `p_vaddr` hold the virtual address (runtime address) for a shared
>> object file and a executable file. But, as stated in the ELF spec,
>> `p_vaddr` might not be correct for a shared object (because it is
>> required to be PIC). So, if that `p_vaddr` is not correct, will those
>> entries in PT_DYNAMIC be correct?
>
> DT_ entries that specify addresses will need to be offset by the base
> address.
Will base address be automatically adjusted by the dynamic linker if
it tries to loaded it at a different base address than that specified
in the `p_vaddr'?
Thanks,
Yubin
