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.

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