<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 2, 2014 at 2:27 PM, Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Wed, Apr 2, 2014 at 10:54 AM, Simon Atanasyan <<a href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>> wrote:<br>

> Hi,<br>
><br>
> On Wed, Apr 2, 2014 at 1:03 AM, Michael Spencer <<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.com</a>> wrote:<br>
>> On Mon, Mar 31, 2014 at 10:54 AM, Simon Atanasyan <<a href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>> wrote:<br>
>>> As far as I understand now it is impossible to generate ELF object<br>
>>> file with relocation sections using yaml2obj tool. I plan to support<br>
>>> ELF relocations in the yaml2obj. Does anybody work on it already or<br>
>>> plan to start this task soon?<br>
>><br>
>> I know of nobody working on this. It would be great to have, thanks!<br>
><br>
> I am going to add "Relocations" optional list to the "Section"<br>
> element. So a YAML file will look like below. An alternative option is<br>
> to introduce new top-level list "Relocation Sections" with "Relocation<br>
> Section" entries. But I think this solution is a little bit over<br>
> designed.<br>
><br>
> Any objections / suggestions?<br>
><br>
> [[<br>
> Sections:<br>
>   - Name: .text<br>
>     Type: SHT_PROGBITS<br>
>     Content: "0000000000000000"<br>
>     AddressAlign: 16<br>
>     Flags: [SHF_ALLOC]<br>
><br>
>   - Name: .rel.text<br>
>     Type: SHT_REL<br>
>     Info: .text<br>
>     AddressAlign: 4<br>
>     Relocations:<br>
>       - !Relocation<br>
>         Offset: 0x1<br>
>         SymbolName: glob1<br>
>         Type: R_MIPS_32<br>
>       - !Relocation<br>
>         Offset: 0x2<br>
>         SymbolName: glob2<br>
>         Type: R_MIPS_CALL16<br>
> ]]<br>
><br>
> --<br>
> Simon Atanasyan<br>
<br>
</div></div>Explicitly modeling relocation sections is correct here. Just one<br>
thing that would need to change. The yaml reader needs to know that<br>
the structure of SHT_REL sections is different, so it would be:<br>
<div class=""><br>
[[<br>
Sections:<br>
  - Name: .text<br>
    Type: SHT_PROGBITS<br>
    Content: "0000000000000000"<br>
    AddressAlign: 16<br>
    Flags: [SHF_ALLOC]<br>
<br>
</div>  - !Relocations<br>
<div class="">    Name: .rel.text<br>
    Type: SHT_REL<br>
    Info: .text<br>
    AddressAlign: 4<br>
    Relocations:<br>
</div>      - Offset: 0x1<br>
        SymbolName: glob1<br>
        Type: R_MIPS_32<br>
      - Offset: 0x2<br>
        SymbolName: glob2<br>
        Type: R_MIPS_CALL16<br>
]]<br>
<br>
When the yaml reader sees the !Relocations tag, it can parse that differently.<br>
<br>
Also, I would prefer to keep names as close to the spec as reasonable,<br>
so Symbol instead of SymbolName.<br></blockquote><div><br></div><div>Yeah, this is what I've tried to do where possible.</div><div><br></div><div><div>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</div>
<div>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)</div><div>2. readability of the YAML format</div>
<div>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.)</div></div><div>4. Sticking close to the spec</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
One thing this doesn't cover is dynamic symbol table vs the normal<br>
symbol table, as both can be referenced by relocations in the same<br>
ELF. This is modeled in ELF by the sh_link field. Not sure how we<br>
should do it here (do we even support dynamic symbol tables yet?).<br>
<span class=""><font color="#888888"><br>
- Michael Spencer<br>
</font></span></blockquote></div><br></div></div>