<div dir="ltr">Nice! Thanks for the update:<br><br>re: ObjC: Perhaps debug_names and .apple_objc could be emitted at the same time to address that issue at least in the short term?<br><br>As for size impact, have you tested this with fission and compressed debug info enabled? (both in terms of whether debug_names is as compressible as the pubnames/pubtypes, and whether it's as efficient for the debugger when it is compressed? (I imagine the decompression might be expensive - maybe it's worth keeping it decompressed, but then the relative cost may be a fair bit higher))</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 13, 2018 at 6:56 AM Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello again,<br>
<br>
It's been nearly six months since my first email, so it's a good time<br>
to recap what has been done here so far. I am happy to report that<br>
stages 1-3 (i.e. producer/consumer in llvm and integration with lldb)<br>
of my original plan are now complete with one caveat.<br>
<br>
The caveat is that the .debug_names section is presently not a full<br>
drop-in replacement for the .apple_*** sections. The reason for that<br>
is that there is no equivalent to the .apple_objc section (which links<br>
an objc class/category name to all of its methods). I did not<br>
implement that, because I do not see a way to embed that kind of<br>
information to this section without some sort of an extension. Given<br>
that this was not required for my use case, I felt it would be best to<br>
leave this to the people working on objc support (*looks at Jonas*) to<br>
work out the details of how to represent that.<br>
<br>
Nonetheless, I believe that the emitted .debug_names section contains<br>
all the data that is required by the standard, and it is sufficient to<br>
pass all tests in the lldb integration test suite on linux (this<br>
doesn't include objc tests). Simple benchmarks also show a large<br>
performance improvement.I have some numbers to illustrate that<br>
(measurements taken by using a release build of lldb to debug a debug<br>
build of clang, clang was built with -mllvm -accel-tables=Dwarf to<br>
enable the accelerator generation, usage of the tables was controlled<br>
by a setting in lldb):<br>
- setting a breakpoint on a non-existing function without the use of<br>
accelerator tables:<br>
real 0m5.554s<br>
user 0m43.764s<br>
sys 0m6.748s<br>
(The majority of this time is spend on building a debug info index,<br>
which is a one-shot thing. subsequent breakpoints would be fast)<br>
<br>
- setting a breakpoint on a non-existing function with accelerator tables:<br>
real 0m3.517s<br>
user 0m3.136s<br>
sys 0m0.376s<br>
(With the index already present, we are able to quickly determine that<br>
there is no match and finish)<br>
<br>
- setting a breakpoint on all "dump" functions without the use of<br>
accelerator tables:<br>
real 0m21.544s<br>
user 0m59.588s<br>
sys 0m6.796s<br>
(Apart from building the index, now we must also parse a bunch of<br>
compile units and line tables to resolve the breakpoint locations)<br>
<br>
- setting a breakpoint on all "dump" functions with accelerator tables:<br>
real 0m23.644s<br>
user 0m22.692s<br>
sys 0m0.948s<br>
(Here we see that this extra work is actually the bottleneck now.<br>
Preliminary analysis shows that majority of this time is spend<br>
inserting line table entries into the middle of a vector, which means<br>
it should be possible to fix this with a smarter implementation).<br>
<br>
As far as object file sizes go, in the resulting clang binary (2.3GB),<br>
the new .debug_names section takes up about 160MB (7%), which isn't<br>
negligible, but considering that it supersedes the<br>
.debug_pubnames/.debug_pubtypes tables whose combined size is 490MB<br>
(21% of the binary), switching to this table (and dropping the other<br>
two) will have a positive impact on the binary size. Further<br>
reductions can be made by merging the individual indexes into one<br>
large index as a part of the link step (which will also increase<br>
debugger speed), but it's hard to quantify the exact impact of that.<br>
<br>
With all of this in mind, I'd like to encourage you to give the new<br>
tables a try. All you need to do is pass -mllvm -accel-tables=Dwarf to<br>
clang while building your project. lldb should use the generated<br>
tables automatically. I'm particularly interested in the interop<br>
scenario. I've checked that readelf is able to make sense of the<br>
generated tables, but if you have any other producer/consumer of these<br>
tables which is independent of llvm, I'd like to know whether we are<br>
compatible with it.<br>
<br>
I'd also like to make the new functionality more easily accessible to<br>
users. I am not sure what our policy here is, but I was thinking of<br>
either including this functionality in -glldb (on non-apple targets);<br>
or by adding a separate -g flag for it (-gdebug-names-section?), with<br>
the goal of eventual inclusion into -glldb. I exclude apple targets<br>
because: a) they already have a thing that works and the lack of<br>
.apple_objc would be a pessimization; b) the different debug info<br>
distribution model means it requires more testing and code (dsymutil).<br>
For other targets this should bring a big performance improvement when<br>
debugging with lldb. The lack of .apple_objc will mean lldb will have<br>
to either index the objc compile units manually, or implement a more<br>
complicated lookup using other information in the section. However,<br>
Objective C is not that widespread outside of apple platforms, so the<br>
impact of this should be minimal.<br>
<br>
What do you think?<br>
<br>
regards,<br>
pavel<br>
</blockquote></div>