This is the mail archive of the
mailing list for the binutils project.
Re: [wip:binutils] Large corefile support
On Sat, Jan 17, 2004 at 03:29:45PM -0500, Ian Lance Taylor wrote:
> Andrew Cagney <email@example.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;
> 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;
/* 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..
IBM OzLabs - Linux Technology Centre