This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Relying on tm-target.h macros in target-tdep.c
- To: Fernando Nasser <fnasser at cygnus dot com>,Orjan Friberg <orjan dot friberg at axis dot com>
- Subject: Re: Relying on tm-target.h macros in target-tdep.c
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 17 Nov 2000 01:25:44 +1100
- Cc: gdb-patches at sourceware dot cygnus dot com
- References: <3A13C9E5.D5465E2C@axis.com> <3A13E1F7.8CCB0A4C@cygnus.com>
Fernando Nasser wrote:
>
> Orjan Friberg wrote:
> >
> > I'm looking to initialise register_bytes in a multi-arched target
> > (cris), which means I do it in my gdbarch_init function. I'd like to
> > rely on the register_raw_size / register_virtual_size function to do the
> > job. I have some thoughts related to that:
> >
> > My register_size function uses macros defined in tm-cris.h. The macros
> > are used only in cris-tdep.c, which means I could move them there, but
> > since the macros (called NUM_GENREGS, NUM_SPECREGS) are related to the
> > architecture's registers it seems they should stay in tm-cris.h. To get
> > around this I would have to #include tm-cris.h in cris-tdep.c. Would
> > that be ok?
> >
>
> First of all, your tm-???.h file is already included. Look in your build
> directory and you'll find a link "tm.h" that points to it (if not your
> configuration is broken). tm.h goes in defs.h, and the latter is included
> everywhere. (BTW, this is explained in the gdb internals manual --
> gdb/doc/gdbint.texinfo).
In theory, the cris-tdep.c file should be so self contained that a
tm.h/tm-chis.h file isn't even needed! Reality, however, may differ.
You may encounter macros that havn't yet been multi-arched.
The documentation is _wrong_.
> > The register_size function (again, called inside gdbarch_init) also uses
> > NUM_REGS, which I've multi-arched, which means NUM_REGS is not defined
> > yet. Would it be ok to defer the multi-arching of that particular macro,
> > and continue to have it as a regular #define in tm-cris.h?
This sounds wrong. The multi-arch macros are not used until after the
entire multi-arch object has been created. Consequently, akward
inter-dependencies are avoided.
> > register_size also uses a macro that depends on current_gdbarch being
> > set to the gdbarch I'm working on in gdbarch_init (for access of data in
> > the tdep struct). Forcing a premature update of current_gdbarch inside
> > gdbarch_init feels like a bad idea.
> >
> > Ok, I see where this is going. Maybe gdbarch_init must be kept pretty
> > much self-contained. I'll try to live with the fact that I will be
> > duplicating information that is already elsewhere in gdb (in opcodes/).
You can certainly pull information in from opcodes or BFD.
However, as Fernando notes ...
> Yes, your gdbarch_init should not rely on things that aren't yet set or
> active yet. It only configures gdbarch to work with targets of your type.
>
> You haven't told us why you need these things in your gdbarch_init,
> and that is your real problem. You should not need any of this in there.
>
> Give us an example of the use of one of these things in there.
> I bet you should be using something from bfd.
enjoy,
Andrew