Re: Build failure with probe patch

[Steve Ellcey <sellcey at imgtec dot com>]

On Wed, 2015-02-18 at 18:57 -0500, Sergio Durigan Junior wrote:
> On Wednesday, February 18 2015, Steve Ellcey wrote:
> 
> > Is anyone else seeing this error when building the top-of-tree gdb:
> >
> >
> > cc1: warnings being treated as errors
> > /scratch/sellcey/gdb-bug/src/gdb/gdb/dtrace-probe.c: In function 'dtrace_get_probes':
> > /scratch/sellcey/gdb-bug/src/gdb/gdb/dtrace-probe.c:624: warning: dereferencing type-punned pointer will break strict-aliasing rules
> > make[1]: *** [dtrace-probe.o] Error 1
> 
> Thanks for your report.
> 
> I don't see anything like this in any of our builders here:
> 
>   <http://gdb-build.sergiodj.net/waterfall>
> 
> > I get this when building gdb on a CentOS 5 system with GCC 4.1.2 but I do not
> > see it when building on a Ubuntu 12.04 system with GCC 4.6.3.  I am not sure
> > if this is due to the old GCC or if it is a legitimate error.
> 
> According to:
> 
>   <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874>
> 
> This warning has been removed from GCC.  And by looking at the code
> referenced by it, I don't see anything wrong there.  So I'd say you can
> ignore this (and probably update your GCC).
> 

I would like to avoid updating GCC if possible.  I build on old systems
because some of our customers use old systems.  I don't know if gdb has
a 'minimal GCC' that it can be compiled with like GCC and some other
projects have.  I tried changing the definition of 'dof' to be '
bfd_byte *' instead of 'struct dtrace_dof_hdr *' and then casting it on
the call to dtrace_process_dof instead of the call to
bfd_malloc_and_get_section.  That got rid of the type punning message
but I wound up seeing:

/scratch/gcc/nightly/src/binutils-gdb/gdb/dtrace-probe.c: In function
'dtrace_get_probes':
/scratch/gcc/nightly/src/binutils-gdb/gdb/dtrace-probe.c:64: warning:
'arg.expr' is used uninitialized in this function
make[1]: *** [dtrace-probe.o] Error 1

Which I do not understand at all.  I will investigate some more and see
if there is a clean way to get this to compile with GCC 4.1.2.

Steve Ellcey
sellcey@imgtec.com