[PATCH] D15965: Add support for dumping relocations in non-relocatable files

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 24 13:13:17 PDT 2016

On Mar 24, 2016 4:08 PM, "Colin LeMahieu" <colinl at codeaurora.org> wrote:
> llvm-objdump wants to print the relocationOffset, so it calls
RelocationRef::relocationOffset which calls
> Since objdump wants the relocation offset, and this pipes down to
ELFObjectFile::getRelocationOffset, at what point is the address supposed
to be asked for?

In llvm-objdump. It can then search the sections to see if one happens to
include that address.

> -----Original Message-----
> From: Rafael EspĂ­ndola [mailto:rafael.espindola at gmail.com]
> Sent: Thursday, March 24, 2016 2:45 PM
> To: reviews+D15965+public+319b19c852e3c4e3 at reviews.llvm.org
> Cc: colinl at codeaurora.org; Hemant Kulkarni <khemant at codeaurora.org>;
Shankar Easwaran <shankare at codeaurora.org>; llvm-commits <
llvm-commits at lists.llvm.org>
> Subject: Re: [PATCH] D15965: Add support for dumping relocations in
non-relocatable files
> On 24 March 2016 at 15:35, Shankar Easwaran <shankare at codeaurora.org>
> > shankare added a reviewer: shankare.
> > shankare added a comment.
> >
> > http://www.sco.com/developers/gabi/latest/ch4.reloc.html
> >
> >   r_offset
> >   This member gives the location at which to apply the relocation
action. For a relocatable file, the value is the byte offset from the
beginning of the section to the storage unit affected by the relocation.
For an executable file or a shared object, the value is the virtual address
of the storage unit affected by the relocation.
> >
> > This shows that the assertion is incorrect, as the ELF ABI suggests
reading relocation records is valid in Executables as well.
> >
> > While relocation offset is not looked up for shared libraries from
> > .rela.dyn and .rela.plt sections, there is a usecase where relocation
> > sections are generated with the linker switch **--emit-relocs**
> And those records have addresses, not offsets. Therefore the assertion is
correct and you may *NOT* remove it.
> CHeers,
> Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160324/7b7341fb/attachment.html>

More information about the llvm-commits mailing list