From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Smith To: Andrew Cagney Cc: GDB Patches Subject: Re: [RFC, RFA] multi-arch PREPARE_TO_PROCEED() Date: Mon, 02 Apr 2001 07:28:00 -0000 Message-id: <3AC88BF9.1060009@redhat.com> References: <3AC39D32.8090709@redhat.com> <3AC4E993.7B23D144@cygnus.com> X-SW-Source: 2001-04/msg00018.html Andrew, Thanks for taking the time to look at this patch. See comments below. Andrew Cagney wrote: > David Smith wrote: > > David two thoughts: > > o is the parameter ``select_it'' needed? Not really, since the only call to PREPARE_TO_PROCEED (in infrun.c) always passes a 1. However: - This macro is already documented in gdbint.texinfo as taking the "select_it" parameter. - If I change the call interface, the possibilities are much higher that I'll screw up the 4 existing implementations of PREPARE_TO_PROCEED. Three of them (hppa-tdep.c, lin-lwp.c, linux-thread.c) should be easy enough to compile, but the last one, m3-nat.c, will not be easy. I've searched and can't find a Mach3 system anywhere (and that port doesn't cross-compile). I was trying not to affect the existing implementations. > > o In your opinion, is there any reason > to have anything other than the > generic_prepare_to_proceed()? > > I'm thinking that we should dump the HP/UX and Linux implementations and > instead, always use your code. So ... can someone test David's change > under linux threads? There is no logical reason why the generic_prepare_to_proceed() couldn't suffice for the 4 existing ports that define PREPARE_TO_PROCEED(). However, the actual implementation gets a bit tricky. None of the 4 existing implementations (hppa-tdep.c, lin-lwp.c, linux-thread.c, m3-nat.c) are multi-arched. The 4 existing implementations also are a bit odd. The Mach3 (m3-nat.c) and HP/UX (hppa-tdep.c) implementations are quite odd in the way they figure out if the threads have been switched. The two linux implementations (linux-thread.c and lin-lwp.c) are fairly normal, with the newest Linux implementation (lin-lwp.c) being pretty straight-forward, except for its integration with thread-db.c. All 4 implementations switch threads in different ways. Here's a bad ascii chart of what they do (and don't do). The list of things to do I got from switch_to_thread() (in thread.c). hppa-tdep.c linux-thread.c lin-lwp.c m3-nat.c Switch "inferior_pid"? X X Flush cached frames? X X Flush register data? X X Update "stop_pc"? Select a new frame? linux-thread.c just sets an internal variable (linuxthreads_step_pid) and then does some magic with that variable in linuxthreads_resume(). m3-nat.c calls a Mach3 specific switch_to_thread() function, which doesn't change inferior_pid at all (?). > > Anyway, I'm ok with the multi-arch part (both with and without the > ``select_it'' parameter) and the change to infrun.c. > > With respect to the possibility of dumping the HP/UX and linux > implementations - MichaelS or MarkK? > > Andrew > I think I've read that the HP/UX port compiles, but can't actually debug programs, so testing that change would be quite difficult... -- David Smith dsmith@redhat.com Red Hat, Inc. http://www.redhat.com 256.704.9222 (direct) 256.837.3839 (fax)