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:
> 
> 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 affects register_byte, register_raw_size, register_virtual_size,
which are implemented via function pointers. 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). register_bytes OTOH, is an int, which means I cannot
"postpone" that decision.

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.)

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

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