This is an archive of the discontinued LLVM Phabricator instance.

[llvm-readobj] Properly decode DF_1_XXX flags
ClosedPublic

Authored by davide on May 23 2015, 4:49 PM.

Details

Summary

Part 2 of D9955 , i.e. llvm-readobj bits.
It seems that readelf puts a "Flags: " string before the actual flag value for FLAGS1 and not FLAGS, e.g.

0x000000000000001e (FLAGS) ORIGIN BIND_NOW
0x000000006ffffffb (FLAGS_1) Flags: NOW ORIGIN

I personally think this doesn't make a lot of sense and considering llvm-readobj already broke format compatibility w/ GNU readelf (at least the version on my system, 2.17.50), not surrounding among others the type name with braces, I just ignored it, so llvm-readobj -dynamic-table will print something like:

0x000000000000001E FLAGS ORIGIN BIND_NOW
0x000000006FFFFFFB FLAGS_1 NOW ORIGIN

If there are objections, I can change the format.

P.S. Too bad all the tests for llvm-readobj rely on executable, maybe at some point this should be changed, but at least the new test doesn't.

Diff Detail

Repository
rL LLVM

Event Timeline

davide updated this revision to Diff 26376.May 23 2015, 4:49 PM
davide retitled this revision from to [llvm-readobj] Properly decode DF_1_XXX flags.
davide updated this object.
davide edited the test plan for this revision. (Show Details)
davide added a reviewer: echristo.
davide set the repository for this revision to rL LLVM.
davide added a subscriber: Unknown Object (MLST).
echristo edited edge metadata.May 23 2015, 5:02 PM

You can also just check in a pre-built one if that makes it easier...

-eric

You can also just check in a pre-built one if that makes it easier...

-eric

Hi,
it doesn't seem to make a lot of difference here. My preference is for not checking in binaries when possible, but if you think it makes more sense, I'll change the test. The only "problem" I may see here is that this test passes flag to the linker via -Wl, but it seems every reasonably modern linker supports this (and the flags).

majnemer added inline comments.
test/tools/llvm-readobj/elf-dtflags.test
3 ↗(On Diff #26376)

Check in assembly or an object file, you cannot rely on the existence of clang.

davide updated this revision to Diff 26377.May 23 2015, 7:42 PM
davide edited edge metadata.
davide removed rL LLVM as the repository for this revision.

Done.
FWIW, there are tests relying on the existence on 'gcc' in the testsuite, so maybe at some point we should document what's allowed to use and what's not (if restrictions are listed somewhere and I missed them, please point them out and sorry in advance for the noise).

Done.
FWIW, there are tests relying on the existence on 'gcc' in the testsuite, so maybe at some point we should document what's allowed to use and what's not (if restrictions are listed somewhere and I missed them, please point them out and sorry in advance for the noise).

The test-suite is different from LLVM's tests as they are execution tests. There are no such tests in the test directory.

$ git grep gcc test | grep RUN | wc -l
0
majnemer added inline comments.May 23 2015, 8:04 PM
test/tools/llvm-readobj/elf-dtflags.test
3–6 ↗(On Diff #26377)

None of the other llvm-readobj tests have a marker before the lit directives other than tests which run an assembler.

davide updated this revision to Diff 26378.May 23 2015, 8:13 PM

David's comments.

This revision was automatically updated to reflect the committed changes.