@jhenderson Please take a look when you have time.
- Changed error codes to more appropriate ones
- Fixed formatting
Thu, Aug 16
Wed, Aug 15
Hi @vleschuk, I just wanted to quickly check-in on this to see if you need any help with making further improvements as suggested?
Tue, Aug 14
DILocation is a subclass of MDNode which is itself a subclass of Metadata. And in Metadata there is "unsigned char Storage" which uses only 2 bits so 6 bits are available here.
Maybe I could add "unsigned char ImplicitCode : 1" and "unsigned char Storage: 7" in class Metadata and so don't increase the DILocation size.
What do you think ?
Mon, Aug 13
The dsymutil part LGTM
Fri, Aug 10
Thanks for your feedback @dblaikie! I've addressed some of it and responded to the rest inline.
Thu, Aug 9
Dsymutil will need to learn to resolve addresses in DW_AT_call_return_pc. Currently, I think it's skipping over them, which means that lldb can't use them.
- Add verifier & bitcode tests, rebase.
- Add complete DWARF generation support for call site entries (i.e, one call site entry per call, DW_AT_call_tail_call emission, and DW_AT_call_return_pc emission).
Wed, Aug 8
Add comment to tests explaining why this works on Darwin.
Tue, Aug 7
I'm abandoning this minor tweak as I am convinced that there is something more fundamentally wrong here.
llvm-dwarfdump doesn't call the right API sequence to show the bug; it requires a DWP, looking up a specific unit by hash via the DWP index, and then scanning all the units. I can envision how to do a unittest for that, but the unittest infrastructure doesn't currently support building a DWP. I can't take the time right now to address this, but I'll keep it on The List.
Fri, Aug 3
looks good. If we end up doing this too often, we can consider changing the blacklist to a whitelist.
I just noticed that llvmObject has an object_error equivalent to std::errc, with a make_error_code method allowing us to turn them into std::error_code for use with the new function. In particular, there are unexpected_eof and parser_failed errors, which might be more appropriate for certain situations in this file. What do you think?
Thu, Aug 2
In the differential you linked we agreed to have the API include an error code as an argument. That still leaves us the option to pass an inconvertibleErrorCode() as the first argument.
Wed, Aug 1
Ping. Any questions?
It looks like my request wasn't addressed either. Can you please fix this soon?
DILocation isn't only used for coverage, I think this should probably be a more general purpose flag, like "isImplicitCode", to indicate that the code was generated as part of a destructor cleanup, an epilogue, or something else that requires the compiler to generate IR that isn't obviously attributed to user source code. Then GCOV can decide for itself how it wants to generate coverage.