This is the mail archive of the
mailing list for the binutils project.
Re: [wip:binutils] Large corefile support
- From: jtc at acorntoolworks dot com (J.T. Conklin)
- To: binutils at sources dot redhat dot com
- Date: Fri, 16 Jan 2004 22:25:33 -0800
- Subject: Re: [wip:binutils] Large corefile support
- References: <400877DC.email@example.com> <firstname.lastname@example.org>
- Reply-to: jtc at acorntoolworks dot com
Ian Lance Taylor <email@example.com> writes:
> Andrew Cagney <firstname.lastname@example.org> writes:
>> A 32-bit BFD has a 32-bit signed file_ptr (limiting SEEK_SET to
>> files up to 2gb). I think the only robust way of handling files
>> larger than that 2gb is to require a 64-bit file_ptr (and hence
> It seems to me that we should try to avoid confusing whether the
> target is 64-bits with the size of a file pointer on the host.
> Admittedly the issue is confused now, because file_ptr is typedefed to
> be bfd_signed_vma. But we don't need to perpetuate the confusion. I
> think we should define file_ptr to be off_t or off64_t, and then
> consistently use ftello or ftello64 and friends if they are available.
> So I guess I would like to see a bit more to your patch--change the
> definition of file_ptr, too. Despite the comment, we know how to set
> the type based on host definitions tested by autoconf--see, e.g., the
> handling of BFD_HOST_64_BIT.
If file_ptr is changed to be defined in terms of long/off_t/off64_t
(depending on what's available on the host), it seems worthwhile to
create a bfd_fseek() that wraps fseek/fseeko/fseeko64 (likewise for
bfd_ftell() and ftell/ftello/ftello64) so that conditionals for each
type are isolated in a single place.