Re: Compilation warning in simple-object-xcoff.c

[Eli Zaretskii]

> From: Ian Lance Taylor 
> Date: Sat, 20 Jan 2018 21:01:09 -0800
> Cc: DJ Delorie , gcc-patches , 
>   gdb-patches 
> 
> On Sat, Jan 20, 2018 at 4:47 AM, Eli Zaretskii  wrote:
> >> Date: Thu, 18 Jan 2018 05:25:20 +0200
> >> From: Eli Zaretskii 
> >> CC: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org,   
> >> gdb-patc...@sourceware.org
> >>
> >> > From: DJ Delorie 
> >> > Cc: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org, 
> >> > gdb-patc...@sourceware.org
> >> > Date: Wed, 17 Jan 2018 15:47:49 -0500
> >> >
> >> > Eli Zaretskii  writes:
> >> >
> >> > > DJ, would the following semi-kludgey workaround be acceptable?
> >> >
> >> > It would be no worse than what we have now, if the only purpose is to
> >> > avoid a warning.
> >> >
> >> > Ideally, we would check to see if we're discarding non-zero values from
> >> > that offset, and not call the callback with known bogus data.  I suppose
> >> > the usefulness of that depends on how often you'll encounter 4Gb+ xcoff64
> >> > files on mingw32 ?
> >>
> >> The answer to that question is "never", AFAIU.
> >
> > So can the patch I proposed be applied, please?
> 
> I committed the patch.

Thanks, Ian!

Re: Compilation warning in simple-object-xcoff.c

[Ian Lance Taylor via gcc-patches]

On Sat, Jan 20, 2018 at 4:47 AM, Eli Zaretskii  wrote:
>> Date: Thu, 18 Jan 2018 05:25:20 +0200
>> From: Eli Zaretskii 
>> CC: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org,   
>> gdb-patc...@sourceware.org
>>
>> > From: DJ Delorie 
>> > Cc: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org, 
>> > gdb-patc...@sourceware.org
>> > Date: Wed, 17 Jan 2018 15:47:49 -0500
>> >
>> > Eli Zaretskii  writes:
>> >
>> > > DJ, would the following semi-kludgey workaround be acceptable?
>> >
>> > It would be no worse than what we have now, if the only purpose is to
>> > avoid a warning.
>> >
>> > Ideally, we would check to see if we're discarding non-zero values from
>> > that offset, and not call the callback with known bogus data.  I suppose
>> > the usefulness of that depends on how often you'll encounter 4Gb+ xcoff64
>> > files on mingw32 ?
>>
>> The answer to that question is "never", AFAIU.
>
> So can the patch I proposed be applied, please?

I committed the patch.

Ian

Re: Compilation warning in simple-object-xcoff.c

[Eli Zaretskii]

> Date: Thu, 18 Jan 2018 05:25:20 +0200
> From: Eli Zaretskii 
> CC: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org,   
> gdb-patc...@sourceware.org
> 
> > From: DJ Delorie 
> > Cc: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org, 
> > gdb-patc...@sourceware.org
> > Date: Wed, 17 Jan 2018 15:47:49 -0500
> > 
> > Eli Zaretskii  writes:
> > 
> > > DJ, would the following semi-kludgey workaround be acceptable?
> > 
> > It would be no worse than what we have now, if the only purpose is to
> > avoid a warning.
> > 
> > Ideally, we would check to see if we're discarding non-zero values from
> > that offset, and not call the callback with known bogus data.  I suppose
> > the usefulness of that depends on how often you'll encounter 4Gb+ xcoff64
> > files on mingw32 ?
> 
> The answer to that question is "never", AFAIU.

So can the patch I proposed be applied, please?

TIA

Re: Compilation warning in simple-object-xcoff.c

[Eli Zaretskii]

> From: DJ Delorie 
> Cc: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Wed, 17 Jan 2018 15:47:49 -0500
> 
> Eli Zaretskii  writes:
> 
> > DJ, would the following semi-kludgey workaround be acceptable?
> 
> It would be no worse than what we have now, if the only purpose is to
> avoid a warning.
> 
> Ideally, we would check to see if we're discarding non-zero values from
> that offset, and not call the callback with known bogus data.  I suppose
> the usefulness of that depends on how often you'll encounter 4Gb+ xcoff64
> files on mingw32 ?

The answer to that question is "never", AFAIU.

Re: Compilation warning in simple-object-xcoff.c

[DJ Delorie]

Eli Zaretskii  writes:

> DJ, would the following semi-kludgey workaround be acceptable?

It would be no worse than what we have now, if the only purpose is to
avoid a warning.

Ideally, we would check to see if we're discarding non-zero values from
that offset, and not call the callback with known bogus data.  I suppose
the usefulness of that depends on how often you'll encounter 4Gb+ xcoff64
files on mingw32 ?

Re: Compilation warning in simple-object-xcoff.c

[Eli Zaretskii]

> From: Andreas Schwab 
> Cc: Eli Zaretskii ,  gcc-patches@gcc.gnu.org,  
> gdb-patc...@sourceware.org
> Date: Tue, 16 Jan 2018 23:00:55 +0100
> 
> On Jan 16 2018, DJ Delorie  wrote:
> 
> > And it's not the host's bit size that counts; there are usually ways to
> > get 64-bit file operations on 32-bit hosts.
> 
> If ACX_LARGEFILE doesn't succeed in enabling those 64-bit file
> operations (thus making off_t a 64-bit type) then you are out of luck
> (or AC_SYS_LARGEFILE doesn't support your host yet).

Yes, AC_SYS_LARGEFILE doesn't support MinGW.

DJ, would the following semi-kludgey workaround be acceptable?

--- libiberty/simple-object-xcoff.c~0   2018-01-12 05:31:04.0 +0200
+++ libiberty/simple-object-xcoff.c 2018-01-17 12:21:08.496186000 +0200
@@ -596,13 +596,19 @@ simple_object_xcoff_find_sections (simpl
  aux = (unsigned char *) auxent;
  if (u64)
{
+ /* Use an intermediate 64-bit type to avoid
+compilation warning about 32-bit shift below on
+hosts with 32-bit off_t which aren't supported by
+AC_SYS_LARGEFILE.  */
+ ulong_type x_scnlen64;
+
  if ((auxent->u.xcoff64.x_csect.x_smtyp & 0x7) != XTY_SD
  || auxent->u.xcoff64.x_csect.x_smclas != XMC_XO)
continue;
 
- x_scnlen = fetch_32 (aux + offsetof (union external_auxent,
-  
u.xcoff64.x_csect.x_scnlen_hi));
- x_scnlen = x_scnlen << 32
+ x_scnlen64 = fetch_32 (aux + offsetof (union external_auxent,
+
u.xcoff64.x_csect.x_scnlen_hi));
+ x_scnlen = x_scnlen64 << 32
   | fetch_32 (aux + offsetof (union external_auxent,
   
u.xcoff64.x_csect.x_scnlen_lo));
}

Re: Compilation warning in simple-object-xcoff.c

[Andreas Schwab]

On Jan 16 2018, DJ Delorie  wrote:

> And it's not the host's bit size that counts; there are usually ways to
> get 64-bit file operations on 32-bit hosts.

If ACX_LARGEFILE doesn't succeed in enabling those 64-bit file
operations (thus making off_t a 64-bit type) then you are out of luck
(or AC_SYS_LARGEFILE doesn't support your host yet).

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Compilation warning in simple-object-xcoff.c

[DJ Delorie]

Well, it should all work fine as long as the xcoff64 file is less than 4
Gb.

And it's not the host's bit size that counts; there are usually ways to
get 64-bit file operations on 32-bit hosts.

Re: Compilation warning in simple-object-xcoff.c

[Eli Zaretskii]

> From: DJ Delorie 
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Tue, 16 Jan 2018 13:00:48 -0500
> 
> 
> I think that warning is valid - the host has a 32-bit limit to file
> sizes (off_t) but it's trying to read a 64-bit offset (in that clause).
> It's warning you that you won't be able to handle files as large as the
> field implies.

If 32-bit off_t cannot handle this, then perhaps this file (or that
function) should not be compiled for a 32-bit host?

Re: Compilation warning in simple-object-xcoff.c

[DJ Delorie]

I think that warning is valid - the host has a 32-bit limit to file
sizes (off_t) but it's trying to read a 64-bit offset (in that clause).
It's warning you that you won't be able to handle files as large as the
field implies.

Can we hide the warning?  Probably.  Should we?  Debatable, as long as
we want 64-bit xcoff support in 32-bit filesystems.

Otherwise, we'd need to detect off_t overflow somehow, down the slippery
slope of reporting the error to the caller...