Re: [PATCH] GDB64 ppc64 compile error patch

[Daniel Jacobowitz <drow@false.org>]

On Wed, Apr 07, 2004 at 02:10:02PM -0700, Kevin Buettner wrote:
> On Wed, 7 Apr 2004 14:37:30 -0500 (CDT)
> Manoj Iyer <manjo@austin.ibm.com> wrote:
> 
> > 
> > This patch fixes compile error when gdb is built as a 64bit binary on a
> > PPC64 platform. ELF_NGREG  ELF_NFPREG and ELF_NVRREG are members of an
> > enum, but they are also defined in a headerfile, so compiler issues error.
> > 
> > gcc -c -m64  -mminimal-toc  -I. -I. -I./config
> > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H
> > -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd
> > -I./../include -I../intl -I./../intl  -DMI_OUT=1 -Wimplicit -Wreturn-type
> > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith
> > -Wuninitialized -Wformat-nonliteral -Wunused-label -Wunused-function
> > ppc-linux-tdep.c
> > cc1: warning: -Wuninitialized is not supported without -O
> > ppc-linux-tdep.c:956: error: parse error before numeric constant
> > make[1]: *** [ppc-linux-tdep.o] Error 1
> > make[1]: Leaving directory `/root/manjo/April07/xxx/new/src/gdb'
> > make: *** [all-gdb] Error 2
> > 
> > This is because ELF_NGREG  ELF_NFPREG and ELF_NVRREG are defined in header
> > files
> > 
> > /usr/include/sys/procfs.h:#define ELF_NFPREG      33      /* includes
> > fpscr */
> > /usr/include/sys/procfs.h:typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
> > /usr/include/asm-ppc/elf.h:#define ELF_NFPREG   33      /* includes fpscr
> > */
> > /usr/include/asm-ppc/elf.h:typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
> > /usr/include/asm-ppc64/elf.h:#define ELF_NFPREG 33      /* includes fpscr
> > */
> > /usr/include/asm-ppc64/elf.h:typedef elf_fpreg_t
> > elf_fpregset_t[ELF_NFPREG];
> > 
> > and the enum
> > 
> > enum {
> >    ELF_NGREG = 48,
> >    ELF_NFPREG = 33,
> >    ELF_NVRREG = 33
> >  };
> > 
> > causes the compiler to interpret ELF_NFPREG = 33, as 33 = 33, etc.
> > 
> > The patch attached fixes this error.
> 
> Thanks for the patch.  Before I apply it (or make other changes to
> avoid the problem), I'd like to have a better understanding of
> precisely what is going wrong.
> 
> A cursory inspection of the sources doesn't give any clue about how
> any of the header files that you mention above are being included in
> ppc-linux-tdep.c.  If we could figure out how the offending system
> header is being included and prevent its inclusion, we could avoid
> redefining the enum constants as macros.  IMO, that would be a
> preferable course of action since we don't want system headers
> tainting any *-tdep.c code anyway.

Almost certainly through <signal.h>, which comes in via one of the
core headers... I can't remember which one, maybe target.h?

I recommend renaming the constants and types used by ppc-linux-tdep.c
instead.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer