Hi Jim,
Am Fr., 8. Nov. 2019 um 19:57 Uhr schrieb Jim Ingham :
>
>
> > On Nov 8, 2019, at 1:53 AM, Konrad Kleine 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
> depen
> On Nov 8, 2019, at 1:53 AM, Konrad Kleine 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
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.
>From what I read in your response I get the feeling that you assume a user
knows about the d
Note first, "break set -f foo.c -l 10" and "break set -f foo.c -n bar" are two
very different breakpoints. In the first case, we are looking for a specific
file & line combination in the line table or inlined functions info. In the
latter case we are searching for a function names bar, and the
On Mon, 04 Nov 2019 16:16:30 +0100, Konrad Kleine via lldb-dev wrote:
> I read the LLDB troubleshooting page [1] and found interesting quotes:
>
> > When setting breakpoints in implementation source files (.c, cpp, cxx,
> .m, .mm, etc), LLDB by
> > default will only search for compile units whose
I read the LLDB troubleshooting page [1] and found interesting quotes:
> When setting breakpoints in implementation source files (.c, cpp, cxx,
.m, .mm, etc), LLDB by
> default will only search for compile units whose filename matches.
> [...]
> % echo "settings set target.inline-breakpoint-stra
