From mboxrd@z Thu Jan 1 00:00:00 1970 From: Todd Whitesel To: jingham@apple.com (Jim Ingham) Cc: toddpw@windriver.com (Todd Whitesel), gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com ("\"Insight (GDB GUI)\"") Subject: Re: non-blocking reads/writes and event loops Date: Wed, 14 Jun 2000 10:47:00 -0000 Message-id: <200006141746.KAA29364@alabama.wrs.com> References: X-SW-Source: 2000-06/msg00128.html > However, threads may need to be used in the case where you only have a > blocking API to control the inferior, but in that case all you are doing is > using threads to fix this local deficiency, not pushing it into the gdb > architecture. I think this is managable. Agreed. If the API designers are dumb enough to trust threads absolutely, and don't give us an option, then well, that's life. -- Todd Whitesel toddpw @ windriver.com >From jimb@zwingli.cygnus.com Wed Jun 14 15:48:00 2000 From: Jim Blandy To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1 Date: Wed, 14 Jun 2000 15:48:00 -0000 Message-id: References: <394428DD.A2EFC21B@precisioninsight.com> <200006120002.e5C02mv14043@delius.kettenis.local> X-SW-Source: 2000-06/msg00129.html Content-length: 411 > If there are major problems, it might be wise to choose a different > name for the PTRACE_{GET,SET}XFPREGS requests to avoid confusion. > That way, nobody will end up with a non-functional GDB (of course the > blame lies entirely with the GDB team for this mess). Well, the blame lies specifically with me, I assume. I did the original SSE debugging support. How should I have done this to avoid the mess? >From ac131313@cygnus.com Wed Jun 14 18:37:00 2000 From: Andrew Cagney To: Todd Whitesel Cc: Jim Ingham , gdb@sourceware.cygnus.com, "Insight (GDB GUI)" Subject: Re: non-blocking reads/writes and event loops Date: Wed, 14 Jun 2000 18:37:00 -0000 Message-id: <394832F2.39D46459@cygnus.com> References: <200006141746.KAA29364@alabama.wrs.com> X-SW-Source: 2000-06/msg00130.html Content-length: 1910 Todd Whitesel wrote: > > > However, threads may need to be used in the case where you only have a > > blocking API to control the inferior, but in that case all you are doing is > > using threads to fix this local deficiency, not pushing it into the gdb > > architecture. I think this is managable. > > Agreed. If the API designers are dumb enough to trust threads absolutely, > and don't give us an option, then well, that's life. For what it is worth, here is the ``It is hard'' reason number two: In addition to the expression evaluator, every physical target (that is the bit that knows how to read/write memory and registers) needs to be inverted. The basic programming model used when developing them requiring a full rewrite. At present a memory/register IO looks like (vaguely): event-loop tty event: (gdb) print ... -> expression-evaluator -> target->read() -> os/remote->read() <- data <- data <- evaluate print at the target level, since we are inverting things, it would need to be broken down into several transactions: event-loop tty-event: (gdb) print ... -> expression-evaluator -> target->request_read () -> os/remote->request_read () event-loop os/remote-event: some data ready -> os/remote->supply_some_of_data() event-loop os/remote-event: some data ready -> os/remote->supply_rest_of_data() (all data ready) -> target->supply_data() ->expression_evaluator->supply_data() event-loop ->expression-evaluator->display() (please don't nit-pick on the detail :-). The point being that you are introducing a fundamentally different programming model into _all_ levels of GDB. You are no longer using procedures but instead passing around messages and writing state machines or similar. All of which are not mechanical. Just making certain that your eyes are open :-) Andrew >From toddpw@windriver.com Wed Jun 14 18:49:00 2000 From: Todd Whitesel To: ac131313@cygnus.com (Andrew Cagney) Cc: toddpw@windriver.com (Todd Whitesel), jingham@apple.com (Jim Ingham), gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com ("Insight (GDB GUI)") Subject: Re: non-blocking reads/writes and event loops Date: Wed, 14 Jun 2000 18:49:00 -0000 Message-id: <200006150149.SAA00358@alabama.wrs.com> References: <394832F2.39D46459@cygnus.com> X-SW-Source: 2000-06/msg00131.html Content-length: 365 > > Agreed. If the API designers are dumb enough to trust threads absolutely, > > and don't give us an option, then well, that's life. > > For what it is worth, here is the ``It is hard'' reason number two: ... > Just making certain that your eyes are open :-) No doubts about that. That's why I said "long term goal"... -- Todd Whitesel toddpw @ windriver.com >From guo@cup.hp.com Thu Jun 15 09:59:00 2000 From: Jimmy Guo To: dan@cgsoftware.com Cc: gdb@sourceware.cygnus.com Subject: rfc: remove gdb.hp/gdb.aCC/namespace.exp test Date: Thu, 15 Jun 2000 09:59:00 -0000 Message-id: X-SW-Source: 2000-06/msg00132.html Content-length: 192 Daniel, Since you've moved namespace.exp & namespace.cc to gdb.c++, the copies in gdb.hp/gdb.aCC are redundant. I can remove these two files if no one objects. - Jimmy Guo, guo@cup.hp.com