This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC, RFA] multi-arch PREPARE_TO_PROCEED()
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [RFC, RFA] multi-arch PREPARE_TO_PROCEED()
- From: David Smith <dsmith at redhat dot com>
- Date: Mon, 02 Apr 2001 09:26:01 -0500
- CC: GDB Patches <gdb-patches at sources dot redhat dot com>
- Organization: Red Hat, Inc.
- References: <3AC39D32.8090709@redhat.com> <3AC4E993.7B23D144@cygnus.com>
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)