From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa] gdbserver signal handling
Date: Thu, 28 Feb 2002 09:25:00 -0000 [thread overview]
Message-ID: <3C7E67F6.4090205@cygnus.com> (raw)
In-Reply-To: <20020228115501.B8496@nevyn.them.org>
> Er, why did you create src/gdb/signals.c?
>
>
> The reason to create src/gdb/signals.c has nothing to do with
> gdbserver; it has to do with:
> - the cleanup I never got to of removing <signal.h> from target.c,
> since <signal.h> is a host header but used for target information.
>
> - the eventual moving of signals.c to be in NATDEPFILES.
>
> I don't want to move it to gdbserver, because I've finally reached no
> code sharing. And because of something you said once, which is now
> true:
>
>> I think, in terms of better splitting up gdbserver and gdb it is pretty
>> much a requirement. I can but dream of the day when GDBSERVER stops
>> including defs.h :-)
>
>
>
> That's why I wanted to do it the above way.
I suspect there is a difference between not including defs.h and
unnecessarily duplicating common code. My memory was that the signal
enums were to be moved to their own header file (so things like
gdbserver could include them).
This gdb/gdbserver/signals.c looks largely like a copy of big chunks of
gdb/signals.c and other similar code. I don't know that gdb developers
want to take on responsability for maintaining such duplication.
Again, I think this can be cleaned up properly, but after the 5.2 branch
goes through.
enjoy,
Andrew
next prev parent reply other threads:[~2002-02-28 17:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-27 20:12 Daniel Jacobowitz
2002-02-28 7:01 ` Andrew Cagney
2002-02-28 8:55 ` Daniel Jacobowitz
2002-02-28 9:25 ` Andrew Cagney [this message]
2002-02-28 9:43 ` Daniel Jacobowitz
2002-02-28 11:29 ` Andrew Cagney
2002-02-28 12:30 ` Daniel Jacobowitz
2002-02-28 12:55 ` Andrew Cagney
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=3C7E67F6.4090205@cygnus.com \
--to=ac131313@cygnus.com \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.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