This is the mail archive of the gdb-patches@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: RFC: MI output during program execution


This isn't just Mac OS X. Any ptrace based system that wants to write a real async target is going to have to spawn a thread somewhere to do it, since ptrace is a blocking call.

This isn't so bad, though. If the platform doesn't have a reliable pthreads implementation, it won't get a flakey gdb, rather, it just won't get an async native target.

Jim



On Oct 3, 2005, at 2:37 PM, Stan Shebs wrote:

Daniel Jacobowitz wrote:


On Tue, Oct 04, 2005 at 08:29:32AM +1300, Nick Roberts wrote:


Daniel Jacobowitz writes:
> Sorry, miscommunication. You don't need approval to create a branch;
> go right ahead.


OK. Thanks.

> I violently dislike the idea of linking gdb with pthreads. I'm
> confident that we can get the benefits without that, however. I've got
> this patch sitting in my queue of things to play with.


I know this will sound stupid but what is the alternative? Using fork?



Doing it "asynchronously" through the GDB event loop, which is I believe the same way we handle remote async targets. All in one process.


Remote async can do it (more-or-less) portably because both the user
and target interaction happen through file descriptors, and the usual
API supports multiplexing. Darwin is problematic because you have
to get some data from events and the like that only have blocking
calls to monitor, so you need a thread per blocking syscall.



This is a little more complicated to design, however, it's got less complexity at runtime. I've spent enough of my life using GDB on systems where pthreads didn't work that I don't want to make GDB dependent on them.


Ideally you'd push the thread/multiplex decision down into target code,
but this would be a semi-ambitious rework to event-loop.c. It might
not matter though, if Darwin (and other configs maybe) can keep using
their own thread-hell code, while something like Linux can assume file
descriptors for inferior monitoring and thus use the general mechanism.


Stan




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