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
Re: entries in PT_DYNAMIC section refer to the correct address at runtime?
On Fri, Sep 15, 2017 at 02:57:36PM +0800, Yubin Ruan wrote: > 2017-09-14 18:25 GMT+08:00 Alan Modra : > > 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'? That might depend on the dynamic linker. glibc ld.so doesn't as far as I know. Build yourself a testcase and inspect the .dynamic section of a shared library or PIE under gdb. -- Alan Modra Australia Development Lab, IBM
Re: Range lists, zero-length functions, linker gc
On Tue, Jun 02, 2020 at 11:06:10AM -0700, David Blaikie via Binutils wrote: > On Tue, Jun 2, 2020 at 9:50 AM Mark Wielaard wrote: > > where I > > would argue the compiler simply needs to make sure that if it generates > > code in separate sections it also should create the DWARF separate > > section (groups). > > I don't think that's practical - the overhead, I believe, is too high. > Headers for each section contribution (ELF headers but DWARF headers > moreso - having a separate .debug_addr, .debug_line, etc section for > each function would be very expensive) would make for very large > object files. With a little linker magic I don't see the neccesity of duplicating the DWARF headers. Taking .debug_line as an example, a compiler could emit the header, opcode, directory and file tables to a .debug_line section with line statements for function foo emitted to .debug_line.foo and for bar to .debug_line.bar, trusting that the linker will combine these sections in order to create an output .debug_line section. If foo code is excluded then .debug_line.foo info will also be dropped if section groups are used. -- Alan Modra Australia Development Lab, IBM
