This is an archive of the discontinued LLVM Phabricator instance.

[yaml2obj] Introduce symbol version section to yaml2obj
AbandonedPublic

Authored by Higuoxing on Nov 24 2018, 3:01 AM.

Details

Summary

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.

Diff Detail

Event Timeline

Higuoxing created this revision.Nov 24 2018, 3:01 AM
Higuoxing updated this revision to Diff 175153.Nov 24 2018, 3:04 AM

format codes

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.

I think this should be fine for now, with the refactoring change mentioned.

tools/yaml2obj/yaml2elf.cpp
277

I agree with James that this ideally should be refactored to a static helper probably.

Higuoxing retitled this revision from [yaml2obj] Make sh_info field editable in raw content section to [yaml2obj] Introduce symbol version section to yaml2obj.Nov 27 2018, 6:07 PM
Higuoxing updated this revision to Diff 175612.EditedNov 27 2018, 6:10 PM

Thank you @jhenderson and @grimar for reviewing

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
https://akkadia.org/drepper/symbol-versioning

PS: I think we need a yaml2obj doc ... If this is on the todo list, I could help

Higuoxing updated this revision to Diff 175615.Nov 27 2018, 6:32 PM

format code

Higuoxing planned changes to this revision.Nov 29 2018, 12:07 AM
Higuoxing updated this revision to Diff 175840.Nov 29 2018, 3:10 AM

Updating D54867: [yaml2obj] Introduce symbol version section to yaml2obj

I implemented .gnu.version_d and .gnu.version_r section

Higuoxing updated this revision to Diff 175841.Nov 29 2018, 3:11 AM

Updating D54867: [yaml2obj] Introduce symbol version section to yaml2obj

I implemented .gnu.version_d and .gnu.version_r section

Sorry, I've been a bit busy over the last couple of days. Where can I find documentation on these two sections you are adding support for?

Sorry, I've been a bit busy over the last couple of days. Where can I find documentation on these two sections you are adding support for?

Thank you for taking time reviewing!

References:

[1] https://akkadia.org/drepper/symbol-versioning
[2] https://refspecs.linuxfoundation.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-generic/symverdefs.html
[3] https://refspecs.linuxfoundation.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-generic/symverrqmts.html

Higuoxing marked an inline comment as done.Nov 29 2018, 7:32 AM
Higuoxing added inline comments.
test/tools/yaml2obj/symbol-version-section.yaml
75

According to https://www.akkadia.org/drepper/symbol-versioning

vda_next: byte offset to the next Elfxx_Verdaux entry. The first entry (pointed to by the Elfxx_Verdef entry, contains the actual defined name. The second and all later entries name predecessor versions.

What if change Auxiliaries to

Name <Required>
Predecessor/Parent <Optional> (Parent is used by `gnu-readelf` and `gnu-objdump`)
Higuoxing updated this revision to Diff 176094.Nov 30 2018, 4:53 AM
This comment was removed by Higuoxing.
Higuoxing updated this revision to Diff 176096.Nov 30 2018, 5:20 AM

Refactor some codes

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.

include/llvm/ObjectYAML/ELFYAML.h
184

Is this supposed to be the Elfxx_Verdaux struct? If so, it should probably be renamed to VersionDefAux, or similar.

185

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.

189

Revision is an Elfxx_Half, so should be a uint16_t, right?

190–191

Ditto for these two fields. They should be Hex16.

192

The is an Elfxx_Word, which is always 32-bits, so should be Hex32.

193

What's the purpose of this field? It doesn't seem to map to any of the struct's fields.

197

Maybe also worth mentioning the section type here, since technically SHT_GNU_verdef sections could be called other things.

209–211

These are all twice the size I'd expect them to be, like in the VersionDef struct above. Why?

212

Similar to the VersionDefParent, this name should be a string.

216–217

Similar to above, these are the wrong types.

221

Similar to above, mention the section type here.

test/tools/yaml2obj/symbol-version-section.yaml
57

Nit: This should be ET_DYN or ET_EXEC, since it's got dynamic information.

75

Sorry, I'm not sure I understand this comment.

tools/yaml2obj/yaml2elf.cpp
235–243

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?

Higuoxing planned changes to this revision.Dec 3 2018, 10:41 PM
Higuoxing abandoned this revision.Feb 21 2019, 5:54 AM

Abandon this patch, since @grimar has implemented .gnu.version_d section (https://reviews.llvm.org/rG623ae72ad46d378d6a2e40abf67d3c5e627bef7c)

Herald added a project: Restricted Project. · View Herald TranscriptFeb 21 2019, 5:54 AM