[PATCH] GDB64 ppc64 compile error patch

[PATCH] GDB64 ppc64 compile error patch

[Manoj Iyer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1614 bytes --]


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
Manoj Iyer

[-- Attachment #2: GDB64 PPC64 patch --]
[-- Type: TEXT/PLAIN, Size: 792 bytes --]

diff -Naurd old/src/gdb/ppc-linux-tdep.c new/src/gdb/ppc-linux-tdep.c
--- old/src/gdb/ppc-linux-tdep.c	2004-02-16 16:49:22.000000000 -0500
+++ new/src/gdb/ppc-linux-tdep.c	2004-04-07 14:24:48.158014232 -0500
@@ -36,6 +36,10 @@
 #include "solib-svr4.h"
 #include "ppc-tdep.h"
 
+#define ELF_NGREG  48
+#define ELF_NFPREG 33
+#define ELF_NVRREG 33
+
 /* The following instructions are used in the signal trampoline code
    on GNU/Linux PPC. The kernel used to use magic syscalls 0x6666 and
    0x7777 but now uses the sigreturn syscalls.  We check for both.  */
@@ -951,13 +955,6 @@
   return addr;
 }
 
-
-enum {
-  ELF_NGREG = 48,
-  ELF_NFPREG = 33,
-  ELF_NVRREG = 33
-};
-
 enum {
   ELF_GREGSET_SIZE = (ELF_NGREG * 4),
   ELF_FPREGSET_SIZE = (ELF_NFPREG * 8)

Re: [PATCH] GDB64 ppc64 compile error patch

[Kevin Buettner]

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.

Kevin

Re: [PATCH] GDB64 ppc64 compile error patch

[Daniel Jacobowitz]

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

Re: [RFC] GDB64 ppc64 compile error patch

[Kevin Buettner]

On Wed, 7 Apr 2004 16:37:43 -0500 (CDT)
Manoj Iyer <manjo@austin.ibm.com> wrote:

> I have attached a pre-processed version of the file ppc-linux-tdep.c, if
> you will scroll down to line #17506 you will see the problem.

Daniel was right, the constants in question were coming in via signal.h.

The constants in question were used in the past in (now rewritten) core
file support.  Since they are not being used any longer, I have committed
a patch which deletes them.  See:

  http://sources.redhat.com/ml/gdb-patches/2004-04/msg00189.html

Kevin