[wip] BFD from an arbitrary object; Was: provide pass-through value in bfd_elf_bfd_from_remote_memory

[Andrew Cagney]

> I agree in general, but I wouldn't do it at the cost of efficiency.
> 
> 
> I'm trying to think ahead to the times we need to expand the list of
> ops, and how many bad things can happen.  Worst case is, bfd expects a
> field that gdb isn't providing, and calls into oblivion.  We need
> something, either a length or an abi version (although length could
> server that purpose too) so that such errors are caught cleanly.

Make "struct bfd_file_ops" vector part of "struct bfd" vis:

struct bfd {
   ...
   struct bfd_file {
     void *data;
     struct bfd_file_ops ops;
   } stream;
   ...
};

have the create bfd method populate all entries (the backward 
compatibility problem) and then when a bfd is given it's stream, update 
non-NULL entries.  GDB kind of sort of does this for its vectors.

but which ever

>> Note that multiple malloc calls aren't much of an issue, though, since
>> BFD uses objalloc, which makes it pretty cheap to allocate memory.
> 
> 
> Does gdb have access to that?  If gdb is creating the interface, gdb
> needs to allocate the structures.
> 
> 
>> > In that case, I'd prefer something less vague than "cookie".  How
>> > about "data"?  I assume most backends will have this point to a
>> > structure with various items in it, whereas "cookie" implies a single
>> > value.  Or a dessert ;-)
> 
>> 
>> Hmmm, you want something less vague than `cookie', so you suggest
>> `data'?  I think I know what you're getting at, but the word is rather
>> ambiguous.
>> 
>> How about `stream' or `storage'?

"cookie" is what <stdio.h> uses (well the one I looked at :-).  "file_data"

> Well, it's a field in a structure called "stream" already, so we're
> talking about stream.ops and stream.data.

Andrew