Adding QNX core-file support to bfd

Adding QNX core-file support to bfd

[Kris Warkentin]

(Posted to both binutils and gdb since there is overlap on who supports core
files)

Our core files require special support and I was hoping that someone might
be able to tell me a better way to do it than we currently do.

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).

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.

Can anyone offer any suggestions for a more elegant way to add this support?

cheers,

Kris

Re: Adding QNX core-file support to bfd

[Nick Clifton]

Hi Kris,

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

Using a target specific define does appear to be the way that all core
file types are supported by the bfd library, so you are not doing
anything unusual or unwarranted.  Since the header files that allow
the core file to be decoded are only available on certain targets, it
makes sense that the inclusion of that particular core file support be
dependent upon the host/build environment, and this environment is
determined at configure time.

Cheers
        Nick

Re: Adding QNX core-file support to bfd

[Kris Warkentin]

> Hi Kris,
>
> > 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.
>
> Using a target specific define does appear to be the way that all core
> file types are supported by the bfd library, so you are not doing
> anything unusual or unwarranted.  Since the header files that allow
> the core file to be decoded are only available on certain targets, it
> makes sense that the inclusion of that particular core file support be
> dependent upon the host/build environment, and this environment is
> determined at configure time.

Okay.  That's good to know.  What I can do to make it a little nicer is to
just put the bare minimum into elf.c and then split our other support
functions out into separate file that will only be compiled for our target.

Second question.  The header file that it requires (nto_debug.h) used to be
in the top level include directory but it seemed to me that any nto specific
includes should be in an 'nto-share' directory in the gdb heirarchy.
Unfortunately, binutils doesn't rely on gdb being present so I'm thinking
that it might need to be in the 'include' dir.  Is there some other way to
do this?  It doesn't look like the include dir is overly cluttered and I
might find some resistance since there aren't really any target specific
headers there.  Perhaps if I just take the definitions I need and put them
into the nto specific file I mentioned earlier?

Kris

Re: Adding QNX core-file support to bfd

[Andrew Cagney]

A technical objective of GDB is to selectively support multiple core 
file formats simultaneously.  I don't know that adding #ifdef's to BFD 
is in line with that objective.  I think the first thing to do is 
investigate what BFD changes are neededed to eliminate these #ifdef's.


> (Posted to both binutils and gdb since there is overlap on who supports core
> files)
> 
> Our core files require special support and I was hoping that someone might
> be able to tell me a better way to do it than we currently do.
> 
> 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.

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

Andrew

Re: Adding QNX core-file support to bfd

[Kris Warkentin]

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

Re: Adding QNX core-file support to bfd

[Kris Warkentin]

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

I'm having trouble coming up with a nice way to do this.  Two problems:

1) Where do I initialize things like this?  Conceivably it could be done in
the 'core_file_p' function but in our case though, we're just using the
generic elf32 stuff.  The other problem is that I'm not sure when
core_file_p gets called.  Our core file support is in elfcore_read_notes()
in elf.c.  We don't have any special code other than that to recognize a QNX
core.

2) How do I deal with the situation when bfd is configured for all targets?
What I had thought to do was to set up a list of alternative core-file
recognition patterns and the corresponding function hooks and then the
target could add its own entries to the list.  That way elfcore_read_notes()
could just run through the list to see what type of core it has.

What about struct elf_backend_data?  We could add a special 'grok_note
function hook' field which elfcore_grok_note() could check first.  It still
leaves me with the problem of where to initialize the backend data but I
think it might be a cleaner solution.

cheers,

Kris