This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa] Add the bfd_iovec



  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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]