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