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

[Michael Snyder <msnyder at redhat dot com>]

Orjan Friberg wrote:
> 
> Fernando Nasser wrote:
> >
> > 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).
> >
> 
> Thanks, I knew about the tm.h-link, but I had missed the connection with
> defs.h.
> 
> > 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.
> >
> 
> Ok, the problem is that I'm adding support for two versions in the same
> chip series, which have different sizes (16 vs 32 bits) for one of the
> registers. The new chip is backwards compatible, which means I cannot
> know for sure which chip version the target actually is until I read the
> version register, in case the binary was compiled for the older chip.

This is not a unique situation.  Other targets with multiple generations
face the same problem.  Go with what the binary says it is, and then 
switch on the fly later if needed.  You cannot assume that you can
read register values from within gdbarch_init.  You might not be 
connected to any target at that time.  Registers might not be available.


> This affects register_byte, register_raw_size, register_virtual_size,
> which are implemented via function pointers.

You should have a different version of each of those functions for
each chip variation.  Unles you want to try and be clever  by having
a single function that detects on the fly what the chip is, but I
do not recommend it if you are doing this for the first time.

You must create a separate gdbarch struct for each chip variation.
The 16-bit gdbarch will point to the 16-bit functions, and so forth.

At runtime (as opposed to initialization time), gdb must decide
which gdbarch to use.

> They make use of the
> information in opcodes/cris-opc.c to get the register sizes by looking
> at the chip version which I've added to my tdep struct (Yes; I hope to
> have the chip version sorted out by the time these functions are called
> -- otherwise I have to rely on the uneducated guess I make in
> gdbarch_init).

Don't do it this way.  You are trying to be too clever.
Implement a separate version of each function for each chip, 
and point to them with separate gdbarch objects.  Let the user
set the chip version by hand, if necessary, until you get the
auto-detection issues straightened out.

> register_bytes OTOH, is an int, which means I cannot
> "postpone" that decision.

Not in your current design -- which is why you shouldn't use it.
Start simple, become more complex as time and foundation permit.
 
> Basically, there is information about registers vs chip versions in
> opcodes/cris-opc.c that I'd like to use (via register_size), instead of
> duplicating that information in gdbarch_init. It's not that big of a
> deal though.
> 
> (When/how I will be able to decide on the actual chip version is another
> story. Right now I'm just adding the framework for supporting both
> chips.)

My impression is that you're trying to do it with a single
gdbarch object.  That's not the idea.

> 
> --
> Orjan Friberg              E-mail: orjan.friberg@axis.com
> Axis Communications AB     Phone:  +46 46 272 17 68