This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC/PATCH multi-arch SMASH_TEXT_ADDRESS


>  * gdbarch.h (SMASH_TEXT_ADDRESS): Add multi-arch defines.
> 	* gdbarch.sh (SMASH_TEXT_ADDRESS): Add rule.
> 	* gdbarch.c (struct gdbarch): Add entry for it.
> 	(startup_gdbarch): Likewise.
> 	(gdbarch_alloc): Default it.
> 	(verify_gdbarch): Skip verify of it.
> 	(gdbarch_dump): Dump it.
> 	(gdbarch_smash_text_address): New function.
> 

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

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.

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

This one was nastier then it first looked, but yes fine.

Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]