This patch lets llvm-readelf dump the content of the BB address map
section in the following format:
Function { At: <address> BB entries [ { Offset: <offset> Size: <size> Metadata: <metadata> }, ... ] } ...
Differential D95511
[llvm-readelf] Support dumping the BB address map section with --bb-addr-map. rahmanl on Jan 26 2021, 11:55 PM. Authored by
Details This patch lets llvm-readelf dump the content of the BB address map Function { At: <address> BB entries [ { Offset: <offset> Size: <size> Metadata: <metadata> }, ... ] } ...
Diff Detail
Unit Tests Event Timeline
Comment Actions You need to add this option to the llvm-readobj and llvm-readelf command guides under llvm/docs/CommandGuide. Ideally, I think you should add gtest unit tests for the libObject code. The lit test would then just (primarily) test the llvm-readobj handling of the potential return values of the parsing code.
Comment Actions Thanks for the comments @grimar
Comment Actions
Comment Actions Note to self: I've not yet reviewed the testing in depth. Need to do that still.
The existing libObject unit tests are patchy at best, unfortunately, so finding a clear-cut precedent is a little tricky. Probably the easiest thing to do would be to follow things like the InvalidSymbolTest in ELFObjectFileTest.cpp to generate an ELFFile instance from YAML written as a string in the code. With a bit of care, you could probably dynamically build up the YAML string from common components to avoid a verbose string literal in each test case. Once you have an ELFFile instance, you can then just call decodeBBAddrMap on that. The aim of this test would be to test the code that is in the library directly, without worring about whatever llvm-readobj does. In particular, you can test all the error paths there, using things like EXPECT_THAT_EXPECTED(..., FailedWithMessage(...));. In the lit test, you could then treat the function as a black box and test only one way of getting the error (to show that the error is handled properly), plus that the dumpign code works as expected in a valid case. Does that make sense?
Comment Actions Thanks @jhenderson. Your explanation was very helpful. Would you please advise on whether I should keep the error paths in the lit tests, as is? Comment Actions Can the output be consumed programmatically? (i.e. is it for example valid yaml or json) Comment Actions Yes, but it's not yaml or json. The output is std::vector<Elf_BBAddrMap> and it is accessible via the library call: ELFFile::decodeBBAddrMap(Elf_Shdr&) (However, the user needs to find the BB address map section). Comment Actions I meant the textual output. It's very close to json - the benefit of it actually being json is that one could script from llvm-readobj output. The other question - looking at the textual output, could it go the next step and produce the association bbaddress - name? My thinking is that the user of the output would find that more valuable (quick scripting, for instance) Comment Actions I see. You're right. The output is similar to json. This is produced by ScopedPrinter. The relevant sources do not point out similarity with JSON at all. Maybe @jhenderson can answer this.
This is a good point. Currently, the bb-address-map is only generated using -fbasic-block-sections=labels which also renumbers the basic block in ascending. So we can say that the MBB number associated with the i'th BB entry is i. Comment Actions The LLVM-style output format for llvm-readobj is not intended to be JSON, although it is somewhat similar. Primarily, the output is intended for ease of testing within the LLVM lit tests. See in particular the second of the following two commits (the first contains some general rules for the output format). https://github.com/llvm/llvm-project/commit/9cad53cfeceed2ef75aa17f0553edd27afd2e950 I don't think it's practical to make the general output JSON-like due to the amount of turbulence this would cause. If there's a particularly strong desire to do this, it should be discussed on llvm-dev in the first instance, I think, and secondly, I think would be best as a third output format (e.g. --elf-output-style=json).
Comment Actions
Comment Actions
Comment Actions
Comment Actions Thanks for the comments @jhenderson
Comment Actions
Comment Actions
Comment Actions @jhenderson and @shenhan I decided to decode the Metadata field right here so the user wouldn't need to worry about it. Comment Actions I'd like to do another review pass of the testing before signing off on this, but generally, this is looking good.
Comment Actions Just a few small suggestions, otherwise this looks good, thanks!
Comment Actions
|
I'm not sure why some functions use _ instead of camelCase, but it's probably best you use the latter. Maybe put it after the notes functions so that we don't switch back and forth between styles too.