This is the mail archive of the gdb@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]

parcelling up struct gdbarch


For the benefit of gdbserver, as discussed, I'd like to break the struct
into two pieces - call them, hypothetically, gdbarch and gdbarch_native.
Things which gdbserver should be able to share, like PC_REGNUM and other
things relating to register layout, or like CANNOT_FETCH_REGISTER, etc.,
would go in the smaller native struct.  They could be fetched from a (split
off from the existing) target specific file, or temporarily added in the
appropriate low-<arch>.c.

Does this sound reasonable?

Also, as a first step I would like to break the data table out of gdbarch.sh
into a separate file.  Is there any reason not to do this?  Then, rather
than introducing another field, I can introduce a second data file for the
native elements.

Native is perhaps not the best name, as e.g. PC_REGNUM need to be known even
in non-native configurations, but calling it gdbarch_target seems wrong to
me.  I'm open to better naming suggestions.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


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