This is the mail archive of the gdb-patches@sources.redhat.com 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: threads and target-function-calls


Michael Snyder wrote:

Andrew Cagney wrote:

>

> > Hey folks,
> >
> > Did you know that (at least on x86 linux), if you have a multi-thread
> > program and you execute a target function call, all the threads get to
> > run?  Doesn't that seem like a bad thing?  Wouldn't we really rather
> > only run the thread that is executing the target function call?

>
> Ha!  That's just the start.  Doing nested inferior function calls on
> alternative threads scrables the dummy frame cache:
> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=468

But... that's just sick.   ;-(
Wait -- you can't do that.  It isn't meaningful to change threads
and then continue/whatever.  It assumes gdb has more control over
scheduling than it actually has.

Oh, I think I misunderstood.  You have in mind this:
	(gdb) print foo()
	[switching thread to xyz]
	Breakpoint 2 in foo ()
	(gdb) print bar()

not this:
	(gdb) print foo ()
	breakpoint 2 in foo()
	(gdb) thread xyz
	(gdb) print bar()

right?
Either.  Or even things like:

	(gdb) print foo()
	[new thread xyx]
	Thread xyz hit breakpoint 2 in foo()
	(gdb) print bar()

(there was talk of trying to only allow one thread to run).

Andrew



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