This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gdbserver (was Re: parcelling up struct gdbarch)


On Tue, Jul 17, 2001 at 02:10:41PM -0400, Andrew Cagney wrote:
> > 
> > How so?  It seems to me to be a much simpler problem, instead.  It
> > means that gdbserver needes target_signal_to_host and friends, which is
> > much easier.  If, that is, we change documentation and gdbserver rather than
> > remote.c.
> 
> 
> If gdbserver is going to pass ptrace() (i.e. target dependant) register 
> bufers then should it also pass back target dependant signal numbers?
> 
> In fact, thinking about it, I know where my comment would have come from 
> - I would have looked at gdbserver and tried to document the current 
> behavour.  Only later did I notice that the comment was wrong and 
> remote.c wasn't doing any conversion :-/
> 
> So, which is correct?

Well, I can argue (and, confusingly, have argued :) both sides here.
I'm not entirely sure.  One advantage of passing target dependent signal
numbers is that if we send a signal that has no target equivalent we
can error before trying to communicate that to the target.  I think
it's outweighed by the fact that a host GDB may not even have the
target's signal numbers available, though.

("But target.c knows them!" you say?  Look where it gets them from -
the host <signal.h>.  The host <signal.h> is wrong for a cross gdb. 
Mind if I add at least a FIXME comment to target.c about this?)

So for signals at least, documentation and gdbserver should change.


For register buffers, see the other half of this thread.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]