[LLVMdev] [yaml2obj] ELF relocation support

[Sean Silva]

On Wed, Apr 2, 2014 at 2:27 PM, Michael Spencer <bigcheesegs at gmail.com>wrote:

> On Wed, Apr 2, 2014 at 10:54 AM, Simon Atanasyan <simon at atanasyan.com>
> wrote:
> > Hi,
> >
> > On Wed, Apr 2, 2014 at 1:03 AM, Michael Spencer <bigcheesegs at gmail.com>
> wrote:
> >> On Mon, Mar 31, 2014 at 10:54 AM, Simon Atanasyan <simon at atanasyan.com>
> wrote:
> >>> As far as I understand now it is impossible to generate ELF object
> >>> file with relocation sections using yaml2obj tool. I plan to support
> >>> ELF relocations in the yaml2obj. Does anybody work on it already or
> >>> plan to start this task soon?
> >>
> >> I know of nobody working on this. It would be great to have, thanks!
> >
> > I am going to add "Relocations" optional list to the "Section"
> > element. So a YAML file will look like below. An alternative option is
> > to introduce new top-level list "Relocation Sections" with "Relocation
> > Section" entries. But I think this solution is a little bit over
> > designed.
> >
> > Any objections / suggestions?
> >
> > [[
> > Sections:
> >   - Name: .text
> >     Type: SHT_PROGBITS
> >     Content: "0000000000000000"
> >     AddressAlign: 16
> >     Flags: [SHF_ALLOC]
> >
> >   - Name: .rel.text
> >     Type: SHT_REL
> >     Info: .text
> >     AddressAlign: 4
> >     Relocations:
> >       - !Relocation
> >         Offset: 0x1
> >         SymbolName: glob1
> >         Type: R_MIPS_32
> >       - !Relocation
> >         Offset: 0x2
> >         SymbolName: glob2
> >         Type: R_MIPS_CALL16
> > ]]
> >
> > --
> > Simon Atanasyan
>
> Explicitly modeling relocation sections is correct here. Just one
> thing that would need to change. The yaml reader needs to know that
> the structure of SHT_REL sections is different, so it would be:
>
> [[
> Sections:
>   - Name: .text
>     Type: SHT_PROGBITS
>     Content: "0000000000000000"
>     AddressAlign: 16
>     Flags: [SHF_ALLOC]
>
>   - !Relocations
>     Name: .rel.text
>     Type: SHT_REL
>     Info: .text
>     AddressAlign: 4
>     Relocations:
>       - Offset: 0x1
>         SymbolName: glob1
>         Type: R_MIPS_32
>       - Offset: 0x2
>         SymbolName: glob2
>         Type: R_MIPS_CALL16
> ]]
>
> When the yaml reader sees the !Relocations tag, it can parse that
> differently.
>
> Also, I would prefer to keep names as close to the spec as reasonable,
> so Symbol instead of SymbolName.
>

Yeah, this is what I've tried to do where possible.

I guess I should just pass on my guiding consideration in the design of the
format: I constantly think about how to find the right balance between
1. low-level control over what ends up in the object file (i.e. being able
to represent most possible ELF files, for obj2yaml eventually to be able to
output the format)
2. readability of the YAML format
3. making it hard to create "nonsense" object files (e.g. with indices
pointing out of range, missing SHT_NULL, global and local symbols out of
order, etc.)
4. Sticking close to the spec

-- Sean Silva


>
> One thing this doesn't cover is dynamic symbol table vs the normal
> symbol table, as both can be referenced by relocations in the same
> ELF. This is modeled in ELF by the sh_link field. Not sure how we
> should do it here (do we even support dynamic symbol tables yet?).
>
> - Michael Spencer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140407/9f0fa710/attachment.html>