rs6000-tdep should probably not depend on the ppc-sim code
Mike Frysinger
vapier@gentoo.org
Wed Mar 14 19:56:00 GMT 2012
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20120314/12d07222/attachment.sig>
More information about the Gdb-patches
mailing list