Re: [RFC, RFA] multi-arch PREPARE_TO_PROCEED()

[David Smith <dsmith@redhat.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)