Compilation warning in simple-object-xcoff.c

Eli Zaretskii eliz@gnu.org
Sun Jan 21 15:45:00 GMT 2018


> From: Ian Lance Taylor <iant@google.com>
> Date: Sat, 20 Jan 2018 21:01:09 -0800
> Cc: DJ Delorie <dj@redhat.com>, gcc-patches <gcc-patches@gcc.gnu.org>, 
> 	gdb-patches <gdb-patches@sourceware.org>
> 
> On Sat, Jan 20, 2018 at 4:47 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Thu, 18 Jan 2018 05:25:20 +0200
> >> From: Eli Zaretskii <eliz@gnu.org>
> >> CC: schwab@linux-m68k.org, gcc-patches@gcc.gnu.org,   gdb-patches@sourceware.org
> >>
> >> > From: DJ Delorie <dj@redhat.com>
> >> > Cc: schwab@linux-m68k.org, gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org
> >> > Date: Wed, 17 Jan 2018 15:47:49 -0500
> >> >
> >> > Eli Zaretskii <eliz@gnu.org> 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.

So now that this patch is committed to upstream libiberty, is it OK to
push it to GDB's copy of the library?



More information about the Gdb-patches mailing list