I am working on D54697, which needs creating .gnu.version_r section. Its entries are defined in sh_info field. So, I think it's reasonable to make sh_info field editable in raw content section.
Whilst I'm not opposed to this in principle, I do wonder if the more correct thing to do is to make .gnu.version_r sections (which I assume have a distinctive ELF type) another kind of ELFYAML section (e.g. like RelocationSection).
I also think a refactor of the error handling is in order. Specifically, basically the same four lines of code exist any time Info or Link can be set. This should probably be pulled out into a separate function. Something like checkSectionIndex or similar.
Updating D54867: [yaml2obj] Introduce symbol version section to yaml2obj
I add .gnu.version_r section into yaml2obj, I don't know if this patch with such size is acceptable ... If needed, I could implement .gnu.version_d as well. Because they are similar ...
Here is my reference
PS: I think we need a yaml2obj doc ... If this is on the todo list, I could help
Thank you for taking time reviewing!
According to https://www.akkadia.org/drepper/symbol-versioning
What if change Auxiliaries to
Name <Required> Predecessor/Parent <Optional> (Parent is used by `gnu-readelf` and `gnu-objdump`)
I'm still not particularly familiar with yaml2obj, so my comments might not always make sense, so feel free to correct me.
On the two flag fields, it might be nice if the user can explicitly specify the flags they want setting (e.g. VER_FLG_BASE), as well as an arbitrary value.
I've not yet reviewed the writeSectionContent functions. I'll do those later.
Is this supposed to be the Elfxx_Verdaux struct? If so, it should probably be renamed to VersionDefAux, or similar.
This should probably be a string, rather than a hex number, since it is just a name. yaml2obj should then automatically add it to a string table, referenced by the sh_link in the VerDef header.
Revision is an Elfxx_Half, so should be a uint16_t, right?
Ditto for these two fields. They should be Hex16.
The is an Elfxx_Word, which is always 32-bits, so should be Hex32.
What's the purpose of this field? It doesn't seem to map to any of the struct's fields.
Maybe also worth mentioning the section type here, since technically SHT_GNU_verdef sections could be called other things.
These are all twice the size I'd expect them to be, like in the VersionDef struct above. Why?
Similar to the VersionDefParent, this name should be a string.
Similar to above, these are the wrong types.
Similar to above, mention the section type here.
Nit: This should be ET_DYN or ET_EXEC, since it's got dynamic information.
Sorry, I'm not sure I understand this comment.
Thanks for the refactor. Given the growing size of this change, would you mind doing it in a separate change and first, please, to reduce the complexity of this change?