From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
Cc: Fabrice Gautier <gautier@email.enst.fr>,
jtc@redback.com, gdb@sources.redhat.com
Subject: Re: gdbserver (was Re: parcelling up struct gdbarch)
Date: Tue, 17 Jul 2001 11:46:00 -0000 [thread overview]
Message-ID: <3B54880B.8090205@cygnus.com> (raw)
In-Reply-To: <20010717112123.A19942@nevyn.them.org>
> 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.
A good rule of thumb is to not mix layers. Something GDB isn't good at.
There are really two cases:
target which is a UNIX like
target which is not UNIX like
In the case of the latter, a fairly arbitrary decision was made to just
use ``enum target_signal'' signal numberings and some cooked up packet.
The signal numbering decision was made on the basis that the protocol
didn't allow the exchange of arbitrary events (it was to UNIX centric).
Andrew
next prev parent reply other threads:[~2001-07-17 11:46 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-13 0:16 parcelling up struct gdbarch Daniel Jacobowitz
2001-07-13 12:35 ` Andrew Cagney
2001-07-13 14:53 ` Daniel Jacobowitz
2001-07-14 8:33 ` Andrew Cagney
2001-07-16 11:25 ` Daniel Jacobowitz
2001-07-16 11:27 ` H . J . Lu
2001-07-16 12:04 ` Andrew Cagney
2001-07-16 12:34 ` J.T. Conklin
2001-07-16 15:30 ` Andrew Cagney
2001-07-16 15:40 ` Daniel Jacobowitz
2001-07-16 17:24 ` gdbserver (was Re: parcelling up struct gdbarch) Fabrice Gautier
2001-07-16 21:17 ` Daniel Jacobowitz
2001-07-16 22:22 ` Fabrice Gautier
2001-07-16 22:28 ` Daniel Jacobowitz
2001-07-17 10:00 ` Andrew Cagney
2001-07-17 10:11 ` Daniel Jacobowitz
2001-07-17 11:10 ` Andrew Cagney
2001-07-17 11:21 ` Daniel Jacobowitz
2001-07-17 11:46 ` Andrew Cagney [this message]
2001-07-17 10:36 ` Quality Quorum
2001-07-16 13:05 ` parcelling up struct gdbarch Daniel Jacobowitz
2001-07-16 15:15 ` Andrew Cagney
2001-07-16 15:49 ` Daniel Jacobowitz
2001-07-17 10:46 ` Andrew Cagney
2001-07-17 11:03 ` Daniel Jacobowitz
2001-07-17 11:37 ` Andrew Cagney
2001-07-18 13:21 ` Daniel Jacobowitz
2001-07-18 22:53 ` Andrew Cagney
2001-07-18 23:22 ` Daniel Jacobowitz
2001-07-19 0:23 ` Daniel Jacobowitz
2001-07-19 7:51 ` Andrew Cagney
2001-07-19 7:44 ` Andrew Cagney
2001-07-18 8:09 ` Andrew Cagney
2001-07-16 23:37 gdbserver (was Re: parcelling up struct gdbarch) Korbel, Michal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B54880B.8090205@cygnus.com \
--to=ac131313@cygnus.com \
--cc=dmj+@andrew.cmu.edu \
--cc=gautier@email.enst.fr \
--cc=gdb@sources.redhat.com \
--cc=jtc@redback.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox