This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: [rfa] Add the bfd_iovec
- From: "Dave Korn" <dk at artimi dot com>
- To: "'Andrew Cagney'" <cagney at gnu dot org>
- Cc: <binutils at sources dot redhat dot com>
- Date: Fri, 16 Apr 2004 19:00:45 +0100
- Subject: RE: [rfa] Add the bfd_iovec
> -----Original Message-----
> From: binutils-owner On Behalf Of Andrew Cagney
> Sent: 16 April 2004 18:28
> > From my reading of your code, you seem to have removed the caching
> > functionality from the bfd layer and moved it into a
> specialized iovec.
>
> Only one IOVEC required the mechanism, and there, for a very
> specalized
> reason (as you note) - a shortage of file descriptors. By
> moving that
> complexity into the FILE IOVEC, BFD proper was simplified.
>
> When it turns out that a generalized FD-cache mechanism is
> needed then,
> the person needing the mechanism can add it :-) (at present
> we've only
> memory, FILE and GDB-inferior IOVECs and only FILE has the problems).
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?
> ISTM?
It Seems To Me.
> 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.
> Also, one of the long ago original threads expressed concern
> at the call
> overhead (Ok I don't be believe it to be significant), but hey this
> looks leaner :-)
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.
> > Isn't it likely to break something if you check this in
> without doing so?
>
> I'm lost. It's the memmory code, that's going to need many changes.
Yes, sorry, as I mentioned in my followup post, I didn't re-read the
thread until after I made the post, and came across your explanation that
the fixes to the memory code would be in a follow-on patch.
Anyway, that certainly addresses all my concerns and curiosities. Thanks
for taking the time to explain.
cheers,
DaveK
--
Can't think of a witty .sigline today....