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]
Other format: [Raw text]

Re: Regcache changes broke MIPS


On Sun, Dec 09, 2001 at 02:52:37PM -0800, Andrew Cagney wrote:
> >Grumph.
> >
> >Because GDB isn't 100% multi-arch, it ends up having to use target macros 
> >from within _initialize_*().  Otherwize non- multi-arch code won't start up 
> >right.  When multi-arch is enabled, a dummy multi-arch vector is used.
> >
> >Anyway, I think there is something even more messed up here.  First, I'm 
> >not sure why that function was called from within an _initialize*() 
> >function.  Secondly, the logic just looks backwards.
> >
> >I'll do some pokeing.
> 
> 
> Hmm, doctor the patient is worse than we thought (and how ironic, this 
> one is my target).
> 
> Briefly, the MIPS still defines certain methods (REGISTER_RAW_SIZE() at 
> least) as macro's mapped onto functions instead of true multi-arch 
> methods.  That is why they are being called when they shouldn't.
> 
> I came up with a patch that fixed just REGISTER_RAW_SIZE() but that 
> didn't fix it - suspect I need to find more.

I think I follow.  Do you actually currently build the register cache
with dummy values (on a multiarch target) and then rebuild it after
gdbarch is initialized?

It seems like there should be a way to register a post-gdbarch,
non-multi-arch-target init function to avoid this.

-- 
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]