This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC/PATCH multi-arch SMASH_TEXT_ADDRESS
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Richard dot Earnshaw at arm dot com, gdb-patches at sources dot redhat dot com
- Date: Sun, 03 Feb 2002 15:24:16 +0000
- Subject: Re: RFC/PATCH multi-arch SMASH_TEXT_ADDRESS
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> FYI, just do this:
>
> gdbarch.sh (SMASH_TEXT_ADDRESS): Add rule.
> gdbarch.h, gdbarch.c: Re-generate.
>
> And then in the gdb directory run:
>
> ./gdbarch.sh
But that makes it too easy :-) Programming should be hard...
>
> It will generate new-gdbarch.[hc] which you can examine/copy into place.
> I noticed slight differences when running this.
>
> > ! #ifdef SMASH_TEXT_ADDRESS
> > ! if (tmpaddr & 1) /* FIXME: delete this line */
> > ! SMASH_TEXT_ADDRESS (tmpaddr);
> > ! #endif
>
>
> I would have been more conservative with this (if
> (SMASH_TEXT_ADDRESS_P()) ... but as you noticed there are only two
> definitions and they both just mask out the bottom bits - the test is
> probably even bogus for HP/UX.
I think the test for "& 1" was probably bogus anyway, regardless of what
other ports might want to define SMASH_TEXT_ADDRESS as. Consider a port
that would incorrectly smash an address with the test removed, I think
that would likely mean that the macro was incorrectly implemented, or that
there is a more serious problem that needs considering. Either way, it
shouldn't be done as a test of a manifest constant.
>
> > + # It is not at all clear why SMASH_TEXT_ADDRESS is not folded into
> > + # ADDR_BITS_REMOVE.
> > + f:2:SMASH_TEXT_ADDRESS:CORE_ADDR:smash_text_address:CORE_ADDR addr:addr:::core_addr_identity::0
>
>
> I agree. Suggest creating a bug report so someone (else - me?) gets to
> investigate further.
Will do.
> This one was nastier then it first looked, but yes fine.
I bet they nearly always are...
R.