This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [2/10] Remove &builtin_type_ from tdep code (amd64/s390/sparc64)
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org (Daniel Jacobowitz)
- Cc: vladimir at codesourcery dot com (Vladimir Prus), gdb-patches at sourceware dot org
- Date: Wed, 13 Jun 2007 15:17:09 +0200 (CEST)
- Subject: Re: [2/10] Remove &builtin_type_ from tdep code (amd64/s390/sparc64)
Daniel Jacobowitz wrote:
> On Wed, Jun 13, 2007 at 03:06:11PM +0200, Ulrich Weigand wrote:
> > However, this macro is not fully equivalent; in particular it
> > is no longer possible to use &builtin_type_double.
>
> You keep saying this, but is it true? :-)
Well, you can take the address, but you won't get the gdbarch-swap
effect any more. So if you were relying on that, it'll break ...
> You can't take the address of a function's return value, but you can
> take the address of a dereference. Of course using
> &builtin_type_double in m68k_gdbarch_init won't work since
> current_gdbarch is NULL then. But we should be able to save
> builtin_type (gdbarch)->builtin_double if we wanted to, I think.
Not really, as the per-gdbarch data elements are allocated only
*after* gdbarch_init returns. (At least those installed using
gdbarch_data_register_post_init as builtin_type is.)
So calling builtin_type (gdbarch) within m68k_gdbarch_init should
itself return NULL.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com