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

[Andrew Cagney <cagney at gnu dot org>]

> 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