[wip:binutils] Large corefile support

Alan Modra amodra@bigpond.net.au
Sun Jan 18 02:15:00 GMT 2004

On Sat, Jan 17, 2004 at 03:29:45PM -0500, Ian Lance Taylor wrote:
> Andrew Cagney <ac131313@redhat.com> writes:
> > > 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?
> Yes, I suppose that is what I am suggesting.  Does anybody think that
> would be a bad idea?

You could reasonably use 32-bit file IO if bfd_vma is 32 bits.

> > 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.
> Good point.  Perhaps the right approach would be something like:
>     if (64-bit type available && 64-bit file I/O available)
>       typedef long long file_ptr;
>     else
>       typedef long file_ptr;
> > 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.
> That would be nice, but seems like an independent issue.

Funny enough, last week I fiddled around with implementing a bfd_int64_t
and bfd_uint64_t type for use with functions like bfd_getb64.  To avoid
lots of silliness when using them, I did the following:

[extract from bfd-in.h]
#define BFD_HOST_64_BIT @BFD_HOST_64_BIT@
#define BFD_HOST_U_64_BIT @BFD_HOST_U_64_BIT@
typedef BFD_HOST_64_BIT bfd_int64_t;
typedef BFD_HOST_U_64_BIT bfd_uint64_t;

#ifndef BFD_HOST_64_BIT
/* Fall back on a 32 bit type.  The idea is to make these types always
   available for function return types, but in the case that
   BFD_HOST_64_BIT is undefined such a function should abort or
   otherwise signal an error.  */
typedef bfd_signed_vma bfd_int64_t;
typedef bfd_vma bfd_uint64_t;

I guess I should polish these changes a little..

Alan Modra
IBM OzLabs - Linux Technology Centre

More information about the Binutils mailing list