This is the mail archive of the gdb-patches@sourceware.org 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: rs6000-tdep should probably not depend on the ppc-sim code


On Wednesday 14 March 2012 13:43:46 Joel Brobecker wrote:
> > the sim is a looooooooong way off from supporting --enable-targets=all. 
> > only sane thing to do is to have the ppc gdb code not enable the sim
> > logic if the default target is non-powerpc.  but i'm not sure if the
> > current gdb framework provides any information for that.
> > 
> > #if WITH_SIM && (DEFAULT_BFD_ARCH == bfd_rs6000_arch)
> > 
> > 	...
> > 
> > #endif
> > 
> > obviously this won't work in actual CPP code.  not sure sure if the gdb
> > peeps have workable suggestions short of opencoding some logic in
> > configure.tgt to append a unique -D to CPPFLAGS to tell the code to not
> > enable things.
> > 
> > relying on the compiler's DCE and doing:
> > 	if (WITH_SIM && DEFAULT_BFD_ARCH == bfd_rs6000_arch)
> > 
> > wouldn't work with lower optimization levels :(
> 
> Just throwing some ideas, since I don't really have a clear idea
> of the best way to fix this.  Could the sim provide an include that
> says which sims are being provided? That way, we would have:
> 
>     #ifdef WITH_SIM
>     #include "sim/something.h"
>     #endif
> 
>     #if WITH_SIM && PPC_SIM_ENABLED
>     ...
>     #endif
> 
> The idea would be to avoid duplicating in GDB's configure the logic
> that's in the sim's configure...
> 
> Or another way: turn that logic into a macro, and share it between
> sim and GDB?

i think the ppc code here is the odd man out.  gdb<->sim interaction should 
normally be gated through the marshaling properties of the gdb protocol.  the 
rs6000 gdb code executing sim funcs directly is something we should discourage 
with pain rather than making easier.

in this particular case, the ppc code seems to be bypassing this protocol to 
quickly get names of the regs.  we can't inline the call in the common ppc sim 
header because it depends on a func that gets generated at build time in the 
sim dir.  so the choices are to avoid calling sim_spr_register_name() 
completely and reworking that code in some other way, or just 
punting/disabling it.  i'm not familiar with these ppc aspects to say what is 
feasible :/.

so i'd be leaning towards the CPPFLAGS hack in the ppc configure.tgt as that 
points out to people "this is not something you should be doing".
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


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