Hi,
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!
- Michael Spencer
Hi,
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
]]
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.
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
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 AtanasyanExplicitly 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.
Agreed. Good point.
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?).
We do not support dynamic symbol tables. If relocation's "Link" field
is not specified explicitly we can link it to the normal symbol table
by default.
Hi,
>> 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
]]
This makes sense to me. It is basically how I imagined this feature being
implemented. I.e. for certain sections there are keys that represent the
"Content" in a smarter way than just a hex string.
It would be really nice to be able to use `!Relocations` to tag the section
like Michael said; I think of it as a "dyn_cast" for choosing the set of
keys that are used to fill in the `Content`. I don't know how easy it is to
do this with YAMLIO but this would be a really great feature to add if it
isn't already implemented. If that is a pain, then I think it would be
acceptable to have both `Content` and `Relocations` in `struct Section` and
use YAMLIO validation <http://llvm.org/docs/YamlIO.html#validation> to make
sure that they both aren't specified.
-- Sean Silva
> Hi,
>
>>> 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 AtanasyanExplicitly 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
Hi Sean,