Re: Adding QNX core-file support to bfd

["Kris Warkentin" <kewarken@qnx.com>]

> > Right now, we have a special elfcore_grok_qnx_note() function that is
called
> > in elf.c in much the same way as elfcore_grok_netbsd_note() is called
(check
> > the namedata for a string and call the function if it matches).
>
> It looks like a dispatch table is needed so that both the QNX and can
> have their support conditionally linked in.

This would be a good idea.  All we need to do is check if the namedata is
"QNX" (NetBSD looks for "NetBSD-CORE").  Perhaps something like:

if( elfcore_grok_special_note && core_namedata_str && strncmp(in.namedata,
core_namedata_str, strlen(core_namedata_str)) == 0){
    if(!elfcore_grok_special_note(abfd, &in))
        goto error;
}

Then a target just initializes elfcore_grok_special_note and
core_namedata_str and all it's other functionality can be in a separate
object.

> > The problem with this is that all of that code and the support functions
for
> > reading our registers, status, etc. is wrapped in #ifdef __QNXTARGET__
which
> > is defined at configure time.  I believe that this is the sort of
clutter
> > that you want to avoid but unfortunately, we rely on some of our
definitions
> > and structures to extract the corefile information.
>
> What exactly is this support code?  Keep in mind that all of the support
> functions et.al. will need to be included in a GDB distribution.

It's just code to decode our registers and notes from our core-file.  We
just make pseudosections in the bfd so that our gdb stuff can read it out.
The only real problem is that it relies on one of our gdb headers.  Nick
Clifton pointed out that we could just put that header with bfd instead of
gdb which solves all our problems.  We just put all our
'qnx_grok_this_and_that()' functions and header includes in that object
which is conditionally compiled.

cheers,

Kris