This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [build] Move unwinder to toplevel libgcc
- From: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Paolo Bonzini <bonzini at gnu dot org>, Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>, Ian Lance Taylor <iant at google dot com>, Steve Ellcey <sje at cup dot hp dot com>, Richard Earnshaw <richard dot earnshaw at arm dot com>, Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>, Nick Clifton <nickc at redhat dot com>, Douglas Rupp <rupp at gnat dot com>, Tristan Gingold <gingold at adacore dot com>, Mike Stump <mikestump at comcast dot net>, Kaz Kojima <kkojima at gcc dot gnu dot org>, David Edelsohn <dje dot gcc at gmail dot com>, Sterling Augustine <augustine dot sterling at gmail dot com>, Arnaud Charlet <charlet at adacore dot com>, java-patches at gcc dot gnu dot org, Nicola Pero <nicola dot pero at meta-innovation dot com>, libstdc++ at gcc dot gnu dot org, Richard Sandiford <rdsandiford at googlemail dot com>
- Date: Mon, 20 Jun 2011 17:20:40 +0200
- Subject: Re: [build] Move unwinder to toplevel libgcc
- References: <yddfwn4pu5u.fsf@manam.CeBiTec.Uni-Bielefeld.DE> <Pine.LNX.4.64.1106201503490.16125@digraph.polyomino.org.uk>
"Joseph S. Myers" <joseph@codesourcery.com> writes:
> On Mon, 20 Jun 2011, Rainer Orth wrote:
>
>> * Move all remaining unwinder-only macros to libgcc: UNW_IVMS_MODE,
>> MD_UNW_COMPATIBLE_PERSONALITY_P, MD_FROB_UPDATE_CONTEXT.
>
> I don't see any sign of macros being poisoned in system.h. For macros
> used in target-independent unwinder code - at least MD_FROB_UPDATE_CONTEXT
> - that used to be defined in the host tm.h but now no longer should be, I
> think poisoning in system.h is appropriate.
Good point: I simply had forgotten about this.
>> * The only unwinder-related macro I haven't moved is
>> LIBGCC2_UNWIND_ATTRIBUTE. It is only defined gcc/config/mips/mips.h.
>> I suppose we would need a libgcc equivalent of tm.h for that,
>> something I didn't want to attack at this point.
>
> What about DWARF_ZERO_REG and PRE_GCC3_DWARF_FRAME_REGISTERS?
> DWARF_REG_TO_UNWIND_COLUMN may be more complicated because it's used on
> the host in rs6000.c (although not in target-independent host code) as
> well as on the target - I suspect that will be a case where duplicating
> the definition (with a comment in one place pointing to the other place as
> needing to be kept consistent, and with the host-side copy renamed to
> facilitate poisoning) may make sense. And all three are defined in
> <arch>.h headers so your reason for moving them separately may apply.
I guess. For the moment, I've concentrated on moving the sources
themselves and the build logic since I've experienced the gcc side
getting in the way of the libgcc side here.
> (There are lots more macros used in the unwinder and on the host for which
> macros predefined with -fbuilding-libgcc may be appropriate in a later
> patch.)
Certainly: your wiki entry gives a good overview. For the moment, I'll
probably concentrate on the build side of things, though. I may attack
gthr* stuff and fp-bit.[ch] next, both of which I can at least partially
test on my targets.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University