Re: some compile errors fo gdb-7.0.1

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 23 February 2010 15:22:33, Harald Koenig wrote:
> Hi Pedro,
> 
> On Feb 18, Pedro Alves wrote:
> 
> > I encourage you to try building cvs head, or a recent
> > snapshot with hp cc so catch other possible tweaks
> > necessary, as gdb 7.1 is close to branching out.
> 
> thanks for the hint!  ok, so here are some more problems at least FYI, 
> not sure if all of them can and must be fixed ?!   
> 

Sure, why not?  Thanks.

> with no specific order:
> 
> -------------------------------------------------------------------------------
> SGI IRIX:
> 
> cc-1028 cc: ERROR File = gdb-CVS-20100222/gdb/varobj.c, Line = 1703
>   The expression used must have a constant value.
> 
>         varobj_update_result r = {*varp};
>                                    ^
> 
> using "gcc -pedantic" you'll get at least a warning about this problem:
> 
> gdb-CVS-20100222/gdb/varobj.c:1703: warning: initializer element is not computable at load time
> gdb-CVS-20100222/gdb/varobj.c:1711: warning: initializer element is not computable at load time
> gdb-CVS-20100222/gdb/varobj.c:1741: warning: initializer element is not computable at load time
> gdb-CVS-20100222/gdb/varobj.c:1818: warning: initializer element is not computable at load time
> gdb-CVS-20100222/gdb/varobj.c:1828: warning: initializer element is not computable at load time
> gdb-CVS-20100222/gdb/varobj.c:1855: warning: initializer element is not computable at load time
> 
> a possible fix for the 1st error would be varobj.c.diff (attached).
> 

Yes, that's the obvious fix, but, your patch doesn't compile in
a couple of places.  :-)

On Tuesday 23 February 2010 15:22:33, Harald Koenig wrote:
> -      varobj_update_result r = {*varp};
> +      varobj_update_result r = {0};
> +      r.varobj = varp;
                    ^ should be `*varp'.

Don't worry, I've fixed it here.

> -------------------------------------------------------------------------------
> old bison/yacc:  
> 
> on some older linux I run into this problem:
> 
>    c-exp.y:2238: error: field 'value' has incomplete type
> 
> these are the distros and bison/byacc versions:
> 
>     suse 9.0	bison 1.75
>     redhat 9	bison 1.35
>     centos 5.0	byacc-1.9-29.2.2
> 
> the attached patch c-exp.y.diff seems to work both with bison-2.3 and
> those older versions...

Right, YYSTYPE is used in other places without the `union' tag.

I've applied the varobj patch to both mainline and the 7.1
branch, and the c-exp.y patch to mainline (only needed there)
under the obviously correct rule.  They're small enough to
not require copyright assignment, but something bigger
than this, or too many of these, and we will.  Let us know
if you're interested to get you started.  Also please take a
look at src/gdb/CONTRIBUTE.

> 
> -------------------------------------------------------------------------------
> Solaris
> 
> on solaris 5.8 (sparc, Sun C 5.7 2005/01/07) and 5.10 (sparc Sun C 5.8 2005/10/13 and x86 Sun C 5.9 SunOS_i386 Patch 124868-01 2007/07/12) the cc complains about unknown __FUNCTION__ :
> 
> 	"gdb-CVS-20100222/bfd/elfxx-sparc.c", line 2944: undefined symbol: __FUNCTION__
> and
> 	"gdb-CVS-20100222/bfd/elf32-i386.c", line 1406: undefined symbol: __FUNCTION__
> 	"gdb-CVS-20100222/bfd/elf32-i386.c", line 3012: undefined symbol: __FUNCTION__
> 
> 
> the short hack in bfd.diff is far from being perfect, just an example
> how to get it compiling because

Looks like you forgot to attach this, but, in any case, bfd is
maintained by the binutils folks, you should take that issue
there.  FYI, the CVS repository is shared between gdb, binutils
and other projects, so you should see the same issue when
building binutils.  Of course, a fix for this should be
quite okay for the gdb 7.1 branch as well, once the binutils
folks approve it.

> (a) it should check for C99 and/or solaris (e.g. if __func__ is really available -- looks like a autoconf thingy;)
> (b) this check/define should be handled elsewhere at one central place
> as there are more files "affected" :
> 
> gdb-CVS-20100222 > grep -rl __FUNCTION__ .
> ./bfd/elfxx-sparc.c
> ./bfd/bfd-in2.h
> ./bfd/nlm32-sparc.c
> ./bfd/elf64-x86-64.c
> ./bfd/elf32-i386.c
> ./bfd/elf32-bfin.c
> ./bfd/bfd-in.h

> ./sim/cris/traps.c

This one's our responsability.  You'll only trip on this if you
build for --target=cris*, though.

> ./gdb/ChangeLog-2004
> ./gdb/ChangeLog-2002
> ./gdb/ChangeLog-2000
> 
> 
> as the ChangeLogs tell that's not really a new problem, IMHO I'd go with ./gdb/ChangeLog-2000 ;-))
> 
> ./gdb/ChangeLog-2000:   * uw-thread.c: Remove __FUNCTION__ GNUism.
> ./gdb/ChangeLog-2002:   __FUNCTION__.
> ./gdb/ChangeLog-2002:   * gnu-nat.c (do_mach_notify_no_senders): Replace __FUNCTION__ with
> ./gdb/ChangeLog-2004:   * ia64-tdep.c (ia64_find_proc_info_x): Do not use __FUNCTION__.
> 
> -------------------------------------------------------------------------------
> AIX 5.3 
> 
> just FYI: while gdb 7.0.1 crashes when trying to start a program
> (typing "gdb a.out" and "r" will SIGSEGV)...
> 
> gdb 7.1.50.20100222-cvs seems to work, at least running and simple break points work...
> -------------------------------------------------------------------------------

Looks like progress to me.  :-)  Kidding aside, the truth is
that we don't have enough people tending for these ports, so
they often rot.  :-(

-- 
Pedro Alves