Re: [wip:binutils] Large corefile support

[Andrew Cagney <ac131313 at redhat dot com>]

> Andrew Cagney <ac131313@redhat.com> writes:
>
>
> > - is requires --enable-64-bit-bfd
> > 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
> > --enable-64-bit-bfd).
>
>
> 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.

I suspect "try" is the operative word :-)

> 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 always use 64-bit file I/O when available?

Note that because off64_t can be conditionally compiled file_ptr will be 
need to be defined using the underlying type.  Otherwize it will make a 
mess of BFD's "bfd.h" file.

Hmm, makes me also wonder if, in a second pass, a rename of file_ptr to 
a more name space proof bfd_offset (better?) is required.

> 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.

Hmm, there's AC_COMPILE_CHECK_SIZEOF but I don't see how to convince it 
to both #define _GNU_SOURCE and #include <stdio.h>.

Andrew