[lldb-dev] [Bug 43959] New: 'process signal ...' should probably NOT stop the process
https://bugs.llvm.org/show_bug.cgi?id=43959 Bug ID: 43959 Summary: 'process signal ...' should probably NOT stop the process Product: lldb Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: mgo...@gentoo.org CC: jdevliegh...@apple.com, lab...@google.com, llvm-b...@lists.llvm.org I think that the current behavior of 'process signal', i.e. that it causes the process to stop with the delivered signal is incorrect and rather incidental of the implementation. While it is expected that a debugger should stop if the signal is sent from outside. However, if a debugger sends the signal there is no reason why the process would stop telling the debugger that it just sent a signal (it should know that!). FWICS this only happens because the signal is sent via kill() rather than ptrace(PTRACE_CONT, ...). Furthermore, I suspect that it doesn't work that way with the per-thread signal logic which actually uses resume actions (but doesn't seem to be used at the moment). The thing is, the ptrace() API doesn't provide the distinction between: (a) sending signal for the 'first' time, i.e. when it should apparently go back to the debugger, (b) sending signal for the 'second' time, i.e. when you decide whether it should hit the process or be discarded. The generic assumption is that signal from debugger falls into (b). While it is technically possible to hack the current behavior using LLDB API (i.e. make ::Signal()+::Resume() pretend that the process was stopped with a signal rather than resuming it), I think that would be a gross hack. It would also require writing another hack for the per-thread signal logic to match. I think it would be better to actually change the behavior to match ptrace() expectations, and make 'process signal ...' deliver the signal without stopping the process. Bug #23318 suggests that FreeBSD is already doing that, and my local NetBSD code was also updated to work the same way. Ideally, we would remove ::Signal() altogether and use resume actions for all signals. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Setting breakpoint on file and function name doesn't work as expected.
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
> 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.
>
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.
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.
>
For the time being and the code working the way it is I'm totally not
against any documentation updates.
>
> 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.*".
>
My example with foo() was very contrived but not unusual. Take any template
function for example:
// foo.h
int foo(){ return 42; }
template
T twice(T arg) { return arg+arg; }
// main.cpp
#include "foo.h"
int main(){return twice(foo());}
When I want to break on the function twice() defined in foo.h I would go
for "-f foo.h -n twice" but I have to go for "-f main.cpp -n
twice". And in terms of DWARF, there's enough to let me do the first
variant:
DW_AT_name ("twice")
DW_AT_decl_file ("/home/kkleine/./foo.h")
DW_AT_decl_line (4)
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.
> 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.
I understand that, the question, as I asked it above, is why we just search
by CU?
> 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.
Okay, that's good to know.
> 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.
>
I will take a look at the code but I already noticed that call to
Comp
[lldb-dev] RFC: Using GitHub Actions for CI testing on the release/* branches
Hi, I would like to start using GitHub Actions[1] for CI testing on the release/* branches. As far as I know we don't have any buildbots listening to the release branches, and I think GitHub Actions are a good way for us to quickly bring-up some CI jobs there. My proposal is to start by adding two post-commit CI jobs to the release/9.x branch. One for building and testing (ninja checka-all) llvm/clang/lld on Linux, Windows, and Mac, and another for detecting ABI changes since the 9.0.0 release. I have already implemented these two CI jobs in my llvm-project fork on GitHub[2][3], but in order to get these running in the main repository, I would need to: 1. Create a new repository in the LLVM organization called 'actions' for storing some custom builds steps for our CI jobs (see [4]). 2. Commit yaml CI definitions to the .github/workflows directory in the release/9.x branch. In the future, I would also like to add buil and tests jobs for other sub-projects once I am able to get those working. In addition to being used for post-commit testing, having these CI definitions in the main tree will make it easier for me (or anyone) to do pre-commit testing for the release branch in a personal fork. It will also allow me to experiment with some new workflows to help make managing the releases much easier. I think this will be a good way to test Actions in a low traffic environment to see if they are something we would want to use for CI on the master branch. Given that we are close to the end of the 9.0.1 cycle, unless there are any strong objections, I would like to get this enabled by Mon Nov 18, to maximize its usefulness. Let me know what you think. Thanks, Tom [1] https://github.com/features/actions [2] https://github.com/tstellar/llvm-project/commit/952d80e8509ecc95797b2ddbf1af40abad2dcf4e/checks?check_suite_id=305765621 [3] https://github.com/tstellar/llvm-project/commit/6d74f1b81632ef081dffa1e0c0434f47d4954423/checks?check_suite_id=303074176 [4] https://github.com/tstellar/actions ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] RFC: Using GitHub Actions for CI testing on the release/* branches
Not having given it deep thought/analysis, nor understanding much of the GIT infrastructure here, but: Sounds good to me, for whatever that's worth :) On Mon, Nov 11, 2019 at 4:32 PM Tom Stellard via llvm-dev < llvm-...@lists.llvm.org> wrote: > Hi, > > I would like to start using GitHub Actions[1] for CI testing on the > release/* > branches. As far as I know we don't have any buildbots listening to the > release branches, and I think GitHub Actions are a good way for us to > quickly > bring-up some CI jobs there. > > My proposal is to start by adding two post-commit CI jobs to the > release/9.x branch. > One for building and testing (ninja checka-all) llvm/clang/lld on Linux, > Windows, and Mac, and another for detecting ABI changes since the 9.0.0 > release. > > I have already implemented these two CI jobs in my llvm-project fork on > GitHub[2][3], > but in order to get these running in the main repository, I would need to: > > 1. Create a new repository in the LLVM organization called 'actions' for > storing some custom > builds steps for our CI jobs (see [4]). > 2. Commit yaml CI definitions to the .github/workflows directory in the > release/9.x > branch. > > In the future, I would also like to add buil and tests jobs for other > sub-projects > once I am able to get those working. > > In addition to being used for post-commit testing, having these CI > definitions in the > main tree will make it easier for me (or anyone) to do pre-commit testing > for the > release branch in a personal fork. It will also allow me to experiment > with some new > workflows to help make managing the releases much easier. > > I think this will be a good way to test Actions in a low traffic > environment to > see if they are something we would want to use for CI on the master branch. > > Given that we are close to the end of the 9.0.1 cycle, unless there are any > strong objections, I would like to get this enabled by Mon Nov 18, to > maximize its > usefulness. Let me know what you think. > > Thanks, > Tom > > [1] https://github.com/features/actions > [2] > https://github.com/tstellar/llvm-project/commit/952d80e8509ecc95797b2ddbf1af40abad2dcf4e/checks?check_suite_id=305765621 > [3] > https://github.com/tstellar/llvm-project/commit/6d74f1b81632ef081dffa1e0c0434f47d4954423/checks?check_suite_id=303074176 > [4] https://github.com/tstellar/actions > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
