From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rearnsha@arm.com>
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Received: (qmail 30991 invoked from network); 3 Feb 2002 15:24:47 -0000
Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3)
  by sources.redhat.com with SMTP; 3 Feb 2002 15:24:47 -0000
Received: by fw-cam.cambridge.arm.com; id PAA13389; Sun, 3 Feb 2002 15:24:46 GMT
Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5)
	id xma013343; Sun, 3 Feb 02 15:24:18 GMT
Received: from cam-mail2.cambridge.arm.com (localhost [127.0.0.1])
	by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id PAA27361;
	Sun, 3 Feb 2002 15:24:17 GMT
Received: from sun18.cambridge.arm.com (sun18.cambridge.arm.com [172.16.2.18])
	by cam-mail2.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id PAA29247;
	Sun, 3 Feb 2002 15:24:16 GMT
Message-Id: <200202031524.PAA29247@cam-mail2.cambridge.arm.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: Andrew Cagney <ac131313@cygnus.com>
cc: Richard.Earnshaw@arm.com, gdb-patches@sources.redhat.com
Reply-To: Richard.Earnshaw@arm.com
Organization: ARM Ltd.
X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd)
X-Fax: +44 1223 400410
X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ.
X-Url: http://www.arm.com/
Subject: Re: RFC/PATCH multi-arch SMASH_TEXT_ADDRESS 
In-reply-to: Your message of "Sat, 02 Feb 2002 16:48:41 EST."
             <3C5C5EB9.3040506@cygnus.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 03 Feb 2002 07:24:00 -0000
From: Richard Earnshaw <rearnsha@arm.com>
X-SW-Source: 2002-02/txt/msg00036.txt.bz2

> 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.