This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Time to expand "Program received signal" ?


> Date: Thu, 15 Nov 2012 20:33:26 +0000
> From: Pedro Alves <palves@redhat.com>
> CC: gnu@toad.com, mark.kettenis@xs4all.nl, brobecker@adacore.com,
>         gdb@sourceware.org
> 
> >>>> It makes no sense to me to have "thread apply all FOO" do nothing
> >>>> for non-threaded inferiors.
> >>>
> >>> No one said it should do nothing.  "Main thread" implies there _is_ a
> >>> thread.
> >>
> >> Yes, and my point is, if people have no problem in calling these special
> >> cases single-threaded (where single implies more than zero), and if
> >> as you say, there _is_ a thread, then the discussion we're having
> >> of whether to say "Thread 1 received ..." is a bit silly.
> > 
> > It's not silly, because these are two different use cases.  In one use
> > case, the _user_ types a thread-related command.  In the other, _GDB_
> > talks about threads in the context of a single-threaded program.  The
> > former case cannot possibly cause user confusion, because it was the
> > user who mentioned threads in the first place.
> > 
> >> Either we assume non-threaded == single-threaded, and admit that in
> >> that case non-threaded inferiors always have at least one thread, or
> >> we don't, and "thread apply all " should not apply to non-threaded
> >> inferiors.  As you called it, it's a matter of self-consistency.
> > 
> > The OP's concern was about the UI, not about GDB's own internal
> > consistency.
> 
> But I'm talking about UI!  "thread apply all" is a user command.
> If you'd expect "thread apply all bt" to produce a backtrace on a
> non-threaded inferior, wouldn't you say that's because there _is_ _a_
> thread in the inferior?  And if so then that thread must have a number
> the user can refer to?  And if so, what is the issue with always
> consistently telling the user the thread that got the signal?
> I can't honestly believe any real user would be confused by this.

We are talking about 2 different users here.  One is who types "thread
apply all SOMETHING" -- this one evidently expects a single-threaded
program to behave as a threaded one with 1 thread.  The other user is
who didn't type any thread-related commands, just had GDB print

  Thread XYZ received signal SIGFOO

This one _might_ be confused.

> Oh well, I'm beginning to consider dropping the patch for now.

That was not my intent.  I don't object to the patch.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]