Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
For backstory/reference: In lld, we choose to store the name of the section .eh_frame truncated as .eh_fram instead of storing the full name in the string table, to allow libunwind to find the section introspectively at runtime. (The string table, where long section names are stored, isn't loaded at runtime.)
I'm a little undecided about this. For one, I think it might be better to keep COFFObjectFile truthful and actually return the real section name, and have code that looks for the .eh_frame section (in llvm-dwarfdump?) accept anything like .eh_fram* (at least for COFF files). But I imagine that llvm-dwardump is using the higher level abstracted object API that abstracts away the object file format specific details - and adding coff specific code there isn't very neat either.
Oh, and also, please add a test case. That should probably be easy to do with yaml2obj.
Writing this test case is too difficult for me. I have update patch by override mapDebugSectionName like [[ https://github.com/llvm-mirror/llvm/blob/c7d9aac7182fec29979a86e544d44e441a76cc0b/lib/Object/MachOObjectFile.cpp#L4623 | MachOObjectFile ]] done.
Oh, if there's such an existing function that can be implemented, that's excellent. Then it's just missing a testcase.
I'd suggest something like this: Link an absolute minimal executable with the properties you want (a section named .eh_fram). Dump this to yaml with the obj2yaml tool. Then create a test e.g. like test/tools/llvm-dwarfdump/uuid.yaml, which consists of the dumped yaml and a RUN line at the start, which runs yaml2obj to convert it back to an executable, and runs llvm-dwarfdump on it, and a CHECK line which checks for some piece of information. In this case it's enough to just check for any information that dwarfdump shows when it found the .eh_fram but didn't show before (e.g. an example of what value you get from fixing this issue).
| lib/Object/COFFObjectFile.cpp | ||
|---|---|---|
| 1287 ↗ | (On Diff #177149) | Thanks, this seems better. |
LGTM
The test input could also be kept in the same file as the test itself, as you had it previously, but it's probably fine either way. This at least allows reusing the input for another test.
Will commit for you a bit later.