The parser is exercised by llvm-objdump using -print-fault-maps. As is
probably obvious, the code itself was "heavily inspired" by
http://reviews.llvm.org/D10434.
Details
Diff Detail
Event Timeline
The actual parser part is LGTM w/minor comments addressed. I don't feel comfortable signing off on the objdump parts.
include/llvm/CodeGen/FaultMaps.h | ||
---|---|---|
74 | Add some comments about compatibility guarantees. It's easier to preempt such things now than introduce them later. | |
118 | Minor style suggestion: | |
136 | I'm not a huge fan of having the types of each field repeated both in the offset code and reader code. Too much room for mismatches. I don't really have a good suggestion on how to do this otherwise though. (What you have is fine, just airing a general frustration.) | |
150 | I really don't like this style of iterator, but it's hard to avoid if you want to do a flyweight parser in this style with variably sized entries. | |
199 | I think you can probably get away with these being inferred which would make the code cleaner. | |
212 | A clearer structure would be: if (i == 0) FFI = getFirstFunctionInfo(); else FFI = getNextFunctionInfo(); OS << FFI; } | |
tools/llvm-objdump/llvm-objdump.cpp | ||
158 | The general option naming convention above would seem to call for a name like "-fault-map-section" Description wise, maybe "Display contents of faultmap section"? I'm trying to get at the fact this is not a hex dump, but not be overly verbose. | |
1235 | The output should probably indicate there isn't a FaultMap table if that's the case. | |
1236 | Is this specific to ELF? Or should it work with any format of object file? | |
1249 | I don't believe StringRef has any backing storage. This looks highly suspicious to say the least. Should this be an std::string instead? | |
1252 | reinterpret_cast?! Couldn't this at least be a static_cast? const char* -> const uint8_t* doesn't seem like it should need a reinterpret_cast | |
1255 | Why can't you just use begin(), end() on StringRef? |
include/llvm/CodeGen/FaultMaps.h | ||
---|---|---|
74 | Done. | |
118 | Done. | |
199 | Do you mean Endianness? If so I tried that and it didn't work. | |
212 | Makes sense, fixed. | |
tools/llvm-objdump/llvm-objdump.cpp | ||
158 | Fixed. | |
1235 | Fixed. | |
1236 | Actually, this worked only with Mach-O. I've added support (and a test) for ELF, and changed printFaultMaps to print an error for other file formats (currently only COFF). | |
1249 | This looks intentional -- as far as I can tell, the sections return a reference to memory they own. | |
1255 | That's a good idea, using bytes_begin() and bytes_end() lets me avoid casting altogether. |
Hey Rafael,
Can you please take a look at the llvm-objdump portion of this patch?
Thanks,
Sanjoy
I have no objections (just small comments), but lhames should probably be the one to give the final OK.
test/CodeGen/X86/implicit-null-check.ll | ||
---|---|---|
2 | Do you really need to use llc? Can't you use llvm-mc or even check in a binary? | |
3 | These are both little endian. Your code is templated on endiannes, so you should probably include a big endian test. |
LGTM, just some minor cosmetic feedback.
include/llvm/CodeGen/FaultMaps.h | ||
---|---|---|
75–76 | I think you have a typo or missing word(s) here (was it supposed to read "version of LLVM that includes it"?). | |
117 | I had the same reaction as Philip on seeing the uintnn_t types replicated in getFoo vs the FooOffset calculation. Did you consider introducing typedefs for each field (e.g. typedef uint64_t FunctionAddrType) so that the offset calculation and read template argument could each be in terms of the typedef, and there'd be just one place mapping each field to its type? | |
124 | Should "idx" be "Idx" instead? | |
132–135 | This could be size_t NextFunctionInfoOffset = FunctionFaultInfosOffset + getNumFaultingPCs() * FunctionFaultInfoSize; to avoid needing to duplicate the whole field list here. |
- address Joseph's review comments
- add an llvm-mc based test
include/llvm/CodeGen/FaultMaps.h | ||
---|---|---|
75–76 | Fixed. | |
117 | That's a good idea, done. | |
124 | Fixed. | |
132–135 | Fixed. | |
test/CodeGen/X86/implicit-null-check.ll | ||
2 | Unless you have strong objections, I'd like to keep this test because I think it is valuable to check that the parser can parse the output of -enable-implicit-null-checks. I'll add a second test that works with llvm-mc. | |
3 | Right now the faultmaps section is generated only for x86_64. |
rafael wrote:
Do you really need to use llc? Can't you use llvm-mc or even check in a binary?
Unless you have strong objections, I'd like to keep this test because I think it is valuable to check that the parser can parse the output of -enable-implicit-null-checks. I'll add a second test that works with llvm-mc.
In which case you should do
llc ... -o %t.s < %s
llvm-mc ... -o %t.o < %t.s
We really should only use "llc -filetype=obj" when there a code path
that is only ever used with that.
Right now the faultmaps section is generated only for x86_64.
Why the template then?
Cheers,
Rafael
LGTM, thanks.
tools/llvm-objdump/llvm-objdump.cpp | ||
---|---|---|
1241–1245 | What's missing that will need to be implemented to support this on COFF? (Not asking you to make any adjustments to this change; just saw this code and wondered about COFF.) |
ping!
Does it make sense to check in the parser now, and wait for Lang to comment on the objdump bits? I don't really need the objdump changes locally, they're just for testing.
Add some comments about compatibility guarantees. It's easier to preempt such things now than introduce them later.