Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #48, string table identification. #49

Merged
merged 1 commit into from
Jul 8, 2020

Conversation

jphickey
Copy link
Contributor

@jphickey jphickey commented Jul 2, 2020

Describe the contribution

Support ELF files that have all strings, including ELF section names, in one single ".strtab" section in the ELF file.

This gives preferential treatment to a section named ".strtab" as this should always be the section which contains the names for the ".symtab" section.

This should also be true of ELF files that contain other strtab sections, such as a ".dynstr" section.

Fixes #48

Testing performed
Confirmed that normal table files built using GCC (e.g. those in the sample framework configuration) are identical, before and after this change is applied.

Confirmed that this is now able to also correctly parse an ELF file from clang which has all strings in a single .strtab section.

Expected behavior changes
Now correctly parses ELF files that do not have a separate .shstrtab and .strtab section.

System(s) tested on
Ubuntu 20.04

Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

Support ELF files that have all strings, including ELF section names,
in one single ".strtab" section in the ELF file.

This gives preferential treatment to a section named ".strtab" as this
should always be the section which contains the names for the ".symtab"
section.

This should also be true of ELF files that contain other strtab sections,
such as a ".dynstr" section.
@jphickey
Copy link
Contributor Author

jphickey commented Jul 2, 2020

Note, this also adds a warning/error exit condition if no usable string table is identified.

In the previous code, it would proceed using offset 0 (the init value of StringTableDataOffset) but this was wrong, and as a result the string data was all garbage data as it read parts of the ELF header interpreted as strings. The program should exit with an error if this offset hasn't been set to a nonzero value by this point.

Additionally, if the tool failed to identify the CFE_TBL_FileDef symbol, it would print an error but still exit with zero status (success) even though no output was written. As a result the build continued as if nothing was wrong, but the table file is missing.

@skliper skliper added CCB:FastTrack bug Something isn't working labels Jul 6, 2020
@astrogeco astrogeco changed the base branch from master to integration-candidate July 8, 2020 13:22
@astrogeco astrogeco merged commit c0c0f38 into nasa:integration-candidate Jul 8, 2020
@skliper skliper added this to the 3.2.0 milestone Aug 21, 2020
@jphickey jphickey deleted the fix-48-strtab branch June 8, 2021 18:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working CCB:FastTrack
Projects
None yet
Development

Successfully merging this pull request may close these issues.

elf2cfetbl does not handle files without a separate ".shstrtab" section
3 participants