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


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


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

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.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

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