[rfa] Add the bfd_iovec

[Andrew Cagney]

>   That sounds completely reasonable then.  I wasn't aware how specialized it
> was, I thought it might be more globally applicable.
> 
> 
>>> Anyway, and regardless, I think that such a mechanism belongs in the 
>>> lower layers (IOVEC) and should not be directly tied to BFD.  
>>> By keeping 
>>> it separate from BFD clients (i.e., GDB) use the underlying 
>>> FD-cache to 
>>> manage other open files - the source code.
> 
> 
>   Erm... that only makes sense to me if you're planning to rewrite gdb to
> use an iovec layer for its own (non-bfd) file access.... should I infer that
> you are, or at any rate that you want it to be an option for the future?

In theory, something like a common module shared with the FILE iovec, in 
reality I've no realistic plan.

Very slightly more realistic is a plan to add a file mmap method.

>>> As you note, each has advantages and disadvantages.  Where 
>>> the interface 
>>> external I'd have done what you suggest.  It isn't so I made it as 
>>> simple and sparse as possible.
> 
> 
>   That's also a reasonable decision; I'm slightly worried, because in things
> like gcc and gdb you tend to have target vectors where you *do* leave a NULL
> in the pointer for an unimplemented function, and people might assume it
> works the same way.  I guess that's something you could take care of simply
> by documenting the requirement.

I'll add the comment.

>   Well, looking lean isn't very important compared to code correctness!  I'd
> say the same applies even when you're adding a NULL test in the wrapper
> layer.  Of course there could always be accessor macros that define to check
> or not check according to configure-time options.

While GDB's architecture vector sees lots of change (and does as you 
suggest) this vector hopefully won't suffer that fate :-).  If it does, 
someone is sure to quickly change things like you suggest.

thanks,
Andrew