> On Nov 8, 2019, at 1:53 AM, Konrad Kleine <[email protected]> wrote:
>
> Jim,
>
> 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.
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.
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.
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:
(lldb) help break set -n
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.
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.
>
> 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?
I am not sure what you are asking me to agree to.
(lldb) break set -n foo -f bar.*
means "set the breakpoint on functions named foo DEFINED in the file "bar.*".
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. 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.)
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.
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.
Jim
>
> Konrad
_______________________________________________
lldb-dev mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
