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

Colin LeMahieu via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 24 13:08:33 PDT 2016

llvm-objdump wants to print the relocationOffset, so it calls RelocationRef::relocationOffset which calls ELFObjectFile::getRelocationOffset

Since objdump wants the relocation offset, and this pipes down to ELFObjectFile::getRelocationOffset, at what point is the address supposed to be asked for?

-----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> wrote:
> 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.


More information about the llvm-commits mailing list