This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Time to expand "Program received signal" ?
> >> John> GDB shouldn't mention threads at all, unless the program being debugged
> >> John> is multi-threaded.
>
> But you didn't address the issue that you can't readily tell whether a program is multi-threaded. It may have had multiple threads but it doesn't now, or it may have more later. This may be true even though it's not linked to libpthread -- that library might not even exist on the OS in question, or it may be linked in static, or the program may simply call the kernel's "create me a thread" syscall.
This isn't rocket science.
If the program "used to" have multiple threads, and only has one now,
it should be treated as single-threaded -- until it creates another thread.
If GDB can't tell whether there's more than one thread, it has to
treat the program as single-threaded.
What does GDB do if the user sets "scheduler-locking on" and GDB isn't
sure whether the target has multiple threads? In general, GDB should
not let itself get into a situation where it doesn't know whether
there are other threads, since in that state it will violate its own
specifications. Just as GDB shouldn't ever print a bogus value for a
variable. The user should be able to depend on anything GDB tells
them about the program. If they have to debug GDB, or work around
well-known bugs in it that make it lie about the state of the program,
they can't trust what it tells them about their own program.
John