<div dir="ltr"><div dir="ltr"><div>Hi Jim,</div><div><br></div></div><div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 8. Nov. 2019 um 19:57 Uhr schrieb Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Nov 8, 2019, at 1:53 AM, Konrad Kleine <<a href="mailto:kkleine@redhat.com" target="_blank">kkleine@redhat.com</a>> wrote:<br>
> <br>
> Jim,<br>
> <br>
> thank you for the explanation. I'm trying to see the situation more from an end user's perspective. When --file or -f have two different meanings depending on how they are combined, that's bad IMHO.<br>
<br>
I don't think that it is bad that the file parameter in a "file and line" breakpoint and the file parameter in a function name breakpoint have different meanings.  That might very well make sense when you think about the kind of search the breakpoint is likely to do.  But this does raise a problem with the documentation. <br></blockquote><div><br></div><div>I think it is dangerous to make too many assumptions and given that people are lazy I think even with a good piece of documentation people would still get it wrong. To me this is similar to a documentation that says: When you cross the street in this direction, go when the light is green. When you cross the street in the other direction, go when the light is red. With any documentation, no matter how accurate it is you will have people not read it entirely. For example, I used -f -n in a way and it worked. Then I enabled LTO and my debugging habits  began to break.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 One way to do it is to try to list all the meanings for each option ("when used in conjunction with...")  I don't think there are actually enough variants that this will bloat the documentation over much, but that's something to watch out for.<br></blockquote><div><br></div><div>For the time being and the code working the way it is I'm totally not against any documentation updates.<br></div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Another thing I've thought about doing is adding the ability to have help include one of the non-optional, non-overlapping options to the command, so you could say:<br>
<br>
(lldb) help break set -n<br>
<br>
and that would tell you that this is a "by function name" breakpoint, and in that case -n means...  That might help reduce the information overload, and give a better sense of what these complex commands do. <br>
<br>
As I said, it would have been better from a documentation standpoint to make all these different breakpoint commands sub-commands of "break set"("break set function", "break set file-and-line', etc...) but I think people would find that too verbose.<br>
<br>
> <br>
> From what I read in your response I get the feeling that you assume a user knows about the difference between CU and his or her source file and the implications it can have when for example LTO is enabled and we make heavy use of inlining. I see this as a problem because source-level debugging for a function name and a file to an end user means exactly that, nomatter where the function is inlined. Do you agree?<br>
<br>
I am not sure what you are asking me to agree to.  <br></blockquote><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
(lldb) break set -n foo -f bar.*<br>
<br>
means "set the breakpoint on functions named foo DEFINED in the file "bar.*".  <br></blockquote><div><br></div><div>My example with foo() was very contrived but not unusual. Take any template function for example:</div><div><br></div><div>// foo.h<br></div><div>int foo(){ return 42; }<br><br>template <typename T><br>T twice(T arg) { return arg+arg; }<br></div><div><br></div><div>// main.cpp<br></div><div>#include "foo.h"<br>int main(){return twice(foo());}</div><div><br></div><div></div><div>When I want to break on the function twice() defined in foo.h I would go for "-f foo.h -n twice<int>" but I have to go for "-f main.cpp -n twice<int>". And in terms of DWARF, there's enough to let me do the first variant:</div><div><br></div><div>DW_AT_name        ("twice<int>")<br>DW_AT_decl_file ("/home/kkleine/./foo.h")<br>DW_AT_decl_line    (4)</div><div><br></div><div>Why don't we respect those DW_AT_decl_file and DW_AT_decl_line? Those are always there, for inlining (with LTO), for templates and for regular functions.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It could mean other things in the context of inlining, for instance you might want to tell lldb to break on the function "foo" whenever it is inlined INTO the CU bar.*.  That's also a perfectly valid thing to do, and you might think "-n -f" was the combination to do that, but it is not what it does.</blockquote><div><br></div><div>I understand that, the question, as I asked it above, is why we just search by CU? <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Again, the feature was intended to disambiguate between different functions with the same name by definition site which the current definition does.  So in this sense the user will have to know what the -f means (and we do need some good solution for documenting this more clearly.) <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Back to your original query...  If the function is defined in a .h file, or gets inlined by LTO, this filtering is trickier, and I didn't implement that behavior when I implemented this breakpoint type.  So in that case, and in the case where LTO inlines a function, the feature isn't implemented correctly.</blockquote><div><br></div><div>Okay, that's good to know.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> The -n searche always looks for out of line and inline instances when doing the search.  So we already get the searcher to all the instances.   You would just have to widen the search beyond "Does the CU match" to try to figure out where the inlined instance was defined.<br></blockquote><div><br></div><div>I will take a look at the code but I already noticed that call to CompUnitPasses which by default returns true and is only overwritten in some circumstances.</div><div><br></div><div>Thank you for taking the time to go through this.</div><div><br></div><div>Konrad<br></div></div></div>