Re: RFC/PATCH multi-arch SMASH_TEXT_ADDRESS

[Richard Earnshaw <rearnsha@arm.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.