This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Fix PR 2250 - multithreaded single-step problems in all-stop mode
- From: Pedro Alves <pedro at codesourcery dot com>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: gdb-patches at sourceware dot org, drow at false dot org
- Date: Mon, 17 Nov 2008 21:02:56 +0000
- Subject: Re: [rfc] Fix PR 2250 - multithreaded single-step problems in all-stop mode
- References: <200811172030.mAHKU54d002481@d12av02.megacenter.de.ibm.com>
On Monday 17 November 2008 20:30:05, Ulrich Weigand wrote:
> In fact other members of the ecs struct should probably be
> local variables, maybe some of them passed explicitly to
> subroutines. ?I think this would help simplify understanding
> the data-flow along handle_inferior_event and its subroutines ...
Agreed, probably, maybe. I few months ago I started doing something like
that and got rid of ecs completely, but then I looked at the result and
noticed that cutting handle_inferior_event into smaller pieces first
(or at the same time) would probably have had better immediate clarity
gains, but I didn't try it. That colides a bit (and possibly goes in the
opposite direction) with just plain getting rid of ecs, as by doing the latter,
you find yourself adjusting callers of callers to pass new flags around (as opposed
to having everything related to an event handy in a single struct). That's a
similar argument to the recent struct value_print_options or replacing
current_language with passing a struct around or similars.
Anyway, I don't have that much strong feelings in either direction, just
telling the world my (possibly bogus) war story. Patches do speak
much louder than words. :-)
--
Pedro Alves