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]

Re: Relying on tm-target.h macros in target-tdep.c


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

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