Hmm... how much is a "significant"? I tried time optimized/lldb --file debug/clang -o "br set -n dump" as a benchmark and I saw a 2-3% slowdown (the variance between individual samples is ~1%, so this is statistically significant).
Thu, Mar 22
Does this patch covers all planned checks or there are any left which will
Wed, Mar 21
The Terminate function is a good place to do this kind of cleanup.
Thank you. This looks good, assuming that the LLDB_DOTEST_ARGS_STR thingy is working as intended.
This looks great. Thank you for doing this.
Tue, Mar 20
Ping @scanon. Is this the kind of change you had in mind?
- Add a couple of more CHECK-NEXTs to the tests.
The way I read this review, there are no major issues with this patch. There are a couple of minor remarks, for which I am waiting for more feedback to see how to go about resolving them. I've added fresh replies to all comments that I think are still unresolved, so you can see what I mean.
- changed "Unknown" to "unknown". I have checked GNU readelf output, they format unknown values completely differently (Unknown TAG value: 0x3e), so this doesn't make the compatibility story worse.
- added FORM, IDX, and AT format providers. These are the ones that are in use currently. Adding the rest is straight-forward.
- I did *not* add the ATOM format provider. To achieve this, we first need to create a separate enum for the DW_ATOM constants, so I left that for a follow-up patch.
Deleting the test build dir is fairly easy. I can whip up a patch for that,
but I'm not sure if that's the part that is bothering you the most here.
Dealing with the log files is a bot more complicated and there doesn't seem
to be a clear consensus on what to do with them. The last discussion about
the (Jan 17: Questions about the LLDB testsuite and improving its
reliability) ended without a clear conclusion. I personally, think it would
be nice to put the log files into the build dir, but I don't feel strongly
enough about it to go around and try to get people to change their habits.
Fri, Mar 16
I like what you did with the test. Originally, I wanted to just compare the raw memory contents, but this keeps it more inline with the spirit of the original test. I have just one question about the list zipping, but otherwise lgtm.
llvm/tools/clang/lib/Basic/SourceManager.cpp:173:17: error: no viable conversion from 'const char ' to 'llvm::StringLiteral'
Thu, Mar 15
I wonder if we shouldn't just fix the TestDisassembleBreakpoint to not require adding every single architecture. That test was added because lldb-server was not removing the traps from the memory read packets. This is something that is completely independent of us later trying to disassemble the memory we got back. To test that, it should be sufficient to compare the memory contents before and after setting a breakpoint.
If we're going to be doing this, could you at least add a description of what the magic 22 value stands for (it's symbolic name and maybe why we should ignore it).
Based on Jason's comment above, it sounds like changing the assertion is good enough.
I think a .ll file would be better abstraction level for this test. You can still hardcode all the paths needed for the test while avoiding spelling out the irrelevant details like debug info abbreviations. But I guess this will work as well...
Wed, Mar 14
I agree with Jim. I deliberately put here only the types that are used for command parsing, since I presume these are the things that the Command/Interpreter modules will depend on (it's not fully clear to me where to draw the line between these two, so it may end up needing to be moved from one to the other in the future, but I think that future will be pretty far away).
This is a version that moves the StringTo*** functions to a new
"OptionArgParser" class. I'm not terribly proud of the name, but I couldn't
think of anything better -- we already have a OptionParser class, so I wanted
to make it clear that this is for parsing the *arguments* of the options.
I've added a bunch of comments to explain how the checks work. Let me know if
this is what you had in mind.
Tue, Mar 13
I don't know if this is the right way to fix this issue, but if it is, I think this function should be refactored/split/whatever somehow to avoid peppering it with "else need_adjust_break_address = true;" everywhere.
Yes, that thought occurred to me almost immediately after I submitted this. I'll try to implement something like that instead.
The ARG_USE_SHARED thingy looks like a typo. I'll make a separate patch for that.
Mon, Mar 12
If you want to, we could bring this up on the dwarf-discuss mailing list. It will be pretty much the same people as here, but the outcome will have more of a binding character :-)
It's used in cmake/modules/LLVM-Config.cmake, and that's the part I need. Without this, the llvm_config macro will behave differently in standalone vs. in-tree builds (i.e., it will be mostly broken in the out-of-tree case as this variable will be empty).
I think the most controversial issue here is the testing... davide may have some thoughts on that.
This drops the LLDBStandalone changes (they are replaced by D44391 on the llvm
side), and simplifies the CMAKE_DL_LIBS logic.
Right, so this will not work for the BUILD_SHARED_LIBS case, and there doesn't seem to be an easy way to make it work from this end. I'm going to try fixing this from the llvm side and come back to this if we still need the pthread/dl fixes.
Ah, yes, another build mode :/. Are you doing a standalone build or not?
I am pretty sure this will be fine for an integrated build, but I have no idea what will it do in the standalone mode...
I am quite new to this part of llvm, so I'll just sit back and learn. I'll just say that a similar error classification would be very useful for the debug_names parser (which I am working on now, and I have noticed the inability to signal that just one of the name indexes is corrupt) and probably a lot of other debug info parsers, so I welcome this effort (though I'm not entirely sure that your usage of llvm::Error is completely idiomatic here).
Does that mean we can remove the .noindex thingy from the build folder name? (In any case, the change seems fine to me).
I like this a lot. That's the kind of change I wanted to do as a follow-up one day. Thank you.
I'll leave the cpp change for others to approve (though it certainly looks simpler than the previous one). I just have a couple of drive-by comments on the test.
I think that adding a path-style field to dwarf (it would probably have to be a vendor extension) is an excellent idea. However, that won't help us with parsing the existing debug info corpus. This isn't going to be 100% correct (e.g. c:\foo.cpp is a valid relative path on unix), but I hope nobody actually uses file names where that matters. If someone like that turns up, then we'd probably have to add a some flag about how the user wants the paths to be treated, as there is no way we can figure out the correct behavior automatically.
Fri, Mar 9
Ah, sorry. I didn't get where you were going with your previous comment. The ObjectFile->Process dependency is something that I think we shouldn't have, but whether it's in an header or implementation file makes little difference to me. So I think moving the #include is fine.
- use DIEInteger functions to avoid computing form sizes manually
- add llvm-dwarfdump -verify lines to check the generated output in tests
- After my adventures on the parsing side (and reading the DWARF 5 form classes section), I've concluded that emitting the DIE offset as a DW_FORM_section_offset is not the right thing to do. The most correct class here seems to be the "reference" class (DW_FORM_refX), so I've changed it to that, although a case could be made for the DW_FORM_dataX forms (which are used by the apple tables) as well. I wish the dwarf standard could be more specific here.