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]

[RFC] target defined OSABI sniffer


It seems that a lot of effort has been put into the multi-arch stuff but
most of it centers around recognizing a binary and setting things up based
on that.  I'm pondering whether that is the right approach in all cases.
Shouldn't the target be telling gdb what it should be doing rather than the
other way around?  I've been looking at different ways of getting gdb to
recognize a QNX binary so that it can set the OSABI properly but shouldn't
the fact that I'm connected to a remote neutrino machine be sufficient?

One possible solution that I'm considering is to put something like a
TARGET_SNIFF_OSABI() type function in the generic sniffer.  That way, when
I'm connected to a remote machine, I can just set the osabi and arch to
match that machine.  Then, if the binary isn't compatable, we can error out.

In the native case, my current_target should KNOW that it's on a Neutrino
box and be able to respond with the appropriate osabi.

Can anyone comment on some possible downsides of this?  Our chief architect
is fairly insistent that we shouldn't need a way to recognize a Neutrino
binary and I'm not having a lot of luck convincing him otherwise.  Just from
my experience chasing these osabi problems, it looks like there are LOTS of
places where the arch can shift under my feet.  I'm thinking that maybe core
files or simulators might be a problem.  The other problem might be that
some targets (ICEs, etc.) may have no way of telling gdb what they are.  In
cases like that, I suppose setting everything based on the binary should be
okay.

Mostly I guess I'm asking whether the target should have a way of overriding
the automatic stuff and saying, "I am targetting this, period."

cheers,

Kris



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