Patch to bfd/aix5ppc-core.c for gdb-6.3 with gcc 4 on AIX5.1

Patch to bfd/aix5ppc-core.c for gdb-6.3 with gcc 4 on AIX5.1

[Rodney Brown]

powerpc-ibm-aix5.1.0.0 gcc version 4.0.1

/bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../gdb-6.3/bfd \
  -I. -D_GNU_SOURCE -DAIX_5_CORE -DAIX_CORE_DUMPX_CORE -DAIX_CORE \
  -DAIX_WEAK_SUPPORT -I. -I../../gdb-6.3/bfd
-I../../gdb-6.3/bfd/../include \
  -I../../gdb-6.3/bfd/../intl -I../intl -W -Wall -Wstrict-prototypes \
  -Wmissing-prototypes -g -O2 -c -o aix5ppc-core.lo \
  ../../gdb-6.3/bfd/aix5ppc-core.c
gcc -DHAVE_CONFIG_H -I. -I../../gdb-6.3/bfd -I. -D_GNU_SOURCE
-DAIX_5_CORE \
  -DAIX_CORE_DUMPX_CORE -DAIX_CORE -DAIX_WEAK_SUPPORT -I.
-I../../gdb-6.3/bfd \
  -I../../gdb-6.3/bfd/../include -I../../gdb-6.3/bfd/../intl -I../intl
-W \
  -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -c \
  ../../gdb-6.3/bfd/aix5ppc-core.c -o aix5ppc-core.o
../../gdb-6.3/bfd/aix5ppc-core.c: In function 'xcoff64_core_p':
../../gdb-6.3/bfd/aix5ppc-core.c:120: error: invalid lvalue in
assignment
../../gdb-6.3/bfd/aix5ppc-core.c:223: warning: \
  assignment discards qualifiers from pointer target type

From a look at aix5ppc-core.c with the CVSWeb interface, the patch for
the return_value warning conflicts with the latest delta.
Since xcoff64_core_p returns a const bfd_target *, I'd prefer declaring
return_value as const.

Diff for /src/bfd/aix5ppc-core.c between version 1.7 and 1.8
version 1.7, 2005/03/03 11:40:55 	version 1.8, 2005/04/18 12:10:57
 	 
-   return_value = abfd->xvec;    /* This is garbage for now.  */
+   return_value = (bfd_target *) abfd->xvec;     /* This is garbage for
now.  */

No current employer disclaimer.
No testsuite run.


2005-07-12  Rodney Brown  <rbrown@bravurasolutions.com.au>

	* aix5ppc-core.c (core_hdr): #define as LHS varient.
	(xcoff64_core_p): Constify return_value variable.

--- bfd/aix5ppc-core.c.orig	Thu Jun 24 14:46:14 2004
+++ bfd/aix5ppc-core.c	Tue Jul 12 00:37:16 2005
@@ -1,5 +1,5 @@
 /* IBM RS/6000 "XCOFF" back-end for BFD.
-   Copyright 2001, 2002, 2004
+   Copyright 2001, 2002, 2004, 2005
    Free Software Foundation, Inc.
    Written by Tom Rix
    Contributed by Redhat.
@@ -44,7 +44,7 @@ int xcoff64_core_file_failing_signal
 #include <sys/ldr.h>
 #include <core.h>
 
-#define	core_hdr(abfd)		((struct core_dumpxx *)
abfd->tdata.any)
+#define	core_hdr(abfd)		(abfd->tdata.any)	/* gcc 4
support */
 
 #define CHECK_FILE_OFFSET(s, v) \
   ((bfd_signed_vma)(v) < 0 || (bfd_signed_vma)(v) >
(bfd_signed_vma)(s).st_size)
@@ -60,7 +60,7 @@ xcoff64_core_p (abfd)
   bfd_vma ld_offset;
   bfd_size_type i;
   struct vm_infox vminfo;
-  bfd_target *return_value = NULL;
+  const bfd_target *return_value = NULL;
 
   /* Get the header.  */
   if (bfd_seek (abfd, 0, SEEK_SET) != 0)
@@ -228,6 +228,9 @@ xcoff64_core_p (abfd)
 
   return return_value;
 }
+
+#undef core_hdr		/* gcc 4.0 support */
+#define	core_hdr(abfd)		((struct core_dumpxx *)
abfd->tdata.any)
 
 /* Return `TRUE' if given core is from the given executable.  */
 

Re: Patch to bfd/aix5ppc-core.c for gdb-6.3 with gcc 4 on AIX5.1

[Nick Clifton]

Hi Rodney,

> powerpc-ibm-aix5.1.0.0 gcc version 4.0.1

> ../../gdb-6.3/bfd/aix5ppc-core.c: In function 'xcoff64_core_p':
> ../../gdb-6.3/bfd/aix5ppc-core.c:120: error: invalid lvalue in
> assignment

I am unable to reproduce this failure :-(

> 2005-07-12  Rodney Brown  <rbrown@bravurasolutions.com.au>
> 
> 	* aix5ppc-core.c (core_hdr): #define as LHS varient.
> 	(xcoff64_core_p): Constify return_value variable.

I am hesitant to apply a patch which does not appear to be needed.

> -#define	core_hdr(abfd)		((struct core_dumpxx *)
> abfd->tdata.any)
> +#define	core_hdr(abfd)		(abfd->tdata.any)	/* gcc 4
> support */

Is this necessary.  You could just alter the use of core_hdr() in 
xcoff64_core_p() and leave the macro alone.

Cheers
   Nick

Re: Patch to bfd/aix5ppc-core.c for gdb-6.3 with gcc 4 on AIX5.1

[Nick Clifton]

Hi Rodney,

> So maybe
> 
> The core_hdr() macro is no longer used here because it would
> expand to code relying on gcc's cast-as-lvalue extension, removed in gcc
> 4.0.

I have checked the patch in with this rewording.

Cheers
   Nick

RE: Patch to bfd/aix5ppc-core.c for gdb-6.3 with gcc 4 on AIX5.1

[Rodney Brown]

gdb-6.3 builds fine with this patch.

I'd reword the comment a little.

!   /* The core_hdr() macro is not used here because it would be
!      casting the LHS of an assignment and some versions of gcc
!      will generate a warning for this.  */ 
 
From http://gcc.gnu.org/gcc-3.4/changes.html

The cast-as-lvalue extension has been removed for C++ and deprecated for
C and Objective-C. In particular, code like this:

        int i;
        (char) i = 5;
        
or this:

        char *p;
        ((int *) p)++;
        
is no longer accepted for C++ and will not be accepted for C and
Objective-C in a future version.

So maybe

The core_hdr() macro is no longer used here because it would
expand to code relying on gcc's cast-as-lvalue extension, removed in gcc
4.0.

Don't know,
Thanks

-----Original Message-----
From: Nick Clifton [mailto:nickc@redhat.com] 
Sent: Monday, 8 August 2005 10:34 PM
To: Rodney Brown
Cc: gdb-patches@sources.redhat.com; binutils@sources.redhat.com
Subject: Re: Patch to bfd/aix5ppc-core.c for gdb-6.3 with gcc 4 on
AIX5.1

Hi Rodney,

> Are you using a gcc 4.1 development compiler?

Yes - but I am not compiling under AIX.  I do not have access to an 
AIX5.1 system, so when I built a cross compiler the build system must 
have left out the core file support.  Silly me.

> I assumed that using the accessor macro was the preferred mechanism.

It is, but when the macro is tied to a single particular function it 
really ought to be defined inside the function.  That way if the code is

ever rearranged it will not be lost.

So - what do you think of the attached, simplified patch ?  If it fixes
the compile time warning then I would be happy to check it in.

Cheers
   Nick

Re: Patch to bfd/aix5ppc-core.c for gdb-6.3 with gcc 4 on AIX5.1

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

Hi Rodney,

> Are you using a gcc 4.1 development compiler?

Yes - but I am not compiling under AIX.  I do not have access to an 
AIX5.1 system, so when I built a cross compiler the build system must 
have left out the core file support.  Silly me.

> I assumed that using the accessor macro was the preferred mechanism.

It is, but when the macro is tied to a single particular function it 
really ought to be defined inside the function.  That way if the code is 
ever rearranged it will not be lost.

So - what do you think of the attached, simplified patch ?  If it fixes
the compile time warning then I would be happy to check it in.

Cheers
   Nick



[-- Attachment #2: aix5.1ppc-core.c.patch --]
[-- Type: text/plain, Size: 1823 bytes --]

Index: bfd/aix5ppc-core.c
===================================================================
RCS file: /cvs/src/src/bfd/aix5ppc-core.c,v
retrieving revision 1.11
diff -c -3 -p -r1.11 aix5ppc-core.c
*** bfd/aix5ppc-core.c	18 Jul 2005 14:13:33 -0000	1.11
--- bfd/aix5ppc-core.c	8 Aug 2005 12:24:45 -0000
***************
*** 1,5 ****
  /* IBM RS/6000 "XCOFF" back-end for BFD.
!    Copyright 2001, 2002, 2003, 2004
     Free Software Foundation, Inc.
     Written by Tom Rix
     Contributed by Red Hat Inc.
--- 1,5 ----
  /* IBM RS/6000 "XCOFF" back-end for BFD.
!    Copyright 2001, 2002, 2003, 2004, 2005
     Free Software Foundation, Inc.
     Written by Tom Rix
     Contributed by Red Hat Inc.
*************** xcoff64_core_p (bfd *abfd)
*** 55,61 ****
    bfd_vma ld_offset;
    bfd_size_type i;
    struct vm_infox vminfo;
!   bfd_target *return_value = NULL;
  
    /* Get the header.  */
    if (bfd_seek (abfd, 0, SEEK_SET) != 0)
--- 55,61 ----
    bfd_vma ld_offset;
    bfd_size_type i;
    struct vm_infox vminfo;
!   const bfd_target *return_value = NULL;
  
    /* Get the header.  */
    if (bfd_seek (abfd, 0, SEEK_SET) != 0)
*************** xcoff64_core_p (bfd *abfd)
*** 111,117 ****
      return return_value;
  
    memcpy (new_core_hdr, &core, sizeof (struct core_dumpxx));
!   core_hdr(abfd) = (char *)new_core_hdr;
  
    /* .stack section.  */
    sec = bfd_make_section_anyway (abfd, ".stack");
--- 111,120 ----
      return return_value;
  
    memcpy (new_core_hdr, &core, sizeof (struct core_dumpxx));
!   /* The core_hdr() macro is not used here because it would be
!      casting the LHS of an assignment and some versions of gcc
!      will generate a warning for this.  */
!   abfd->tdata.any = new_core_hdr;
  
    /* .stack section.  */
    sec = bfd_make_section_anyway (abfd, ".stack");

RE: Patch to bfd/aix5ppc-core.c for gdb-6.3 with gcc 4 on AIX5.1

[Rodney Brown]

Are you using a gcc 4.1 development compiler? Has the assertion on
casts in the left-hand side of assignments weakened?

bash-3.00$ uname -a
AIX bullwinkle 1 5 0052570A4C00
bash-3.00$ gcc -v	# configured and built on the box
Using built-in specs.
Target: powerpc-ibm-aix5.1.0.0
Configured with: ../gcc-4.0.1/configure 
Thread model: aix
gcc version 4.0.1

I assumed that using the accessor macro was the preferred mechanism.
The error lines & compile are from the build.log - with the compile
line wrapped to 80 char.
 
-----Original Message-----
From: Nick Clifton [mailto:nickc@redhat.com] 
Sent: Tuesday, 2 August 2005 9:05 PM
To: Rodney Brown
Cc: gdb-patches@sources.redhat.com; binutils@sources.redhat.com
Subject: Re: Patch to bfd/aix5ppc-core.c for gdb-6.3 with gcc 4 on
AIX5.1

Hi Rodney,

> powerpc-ibm-aix5.1.0.0 gcc version 4.0.1

> ../../gdb-6.3/bfd/aix5ppc-core.c: In function 'xcoff64_core_p':
> ../../gdb-6.3/bfd/aix5ppc-core.c:120: error: invalid lvalue in
> assignment

I am unable to reproduce this failure :-(

> 2005-07-12  Rodney Brown  <rbrown@bravurasolutions.com.au>
> 
> 	* aix5ppc-core.c (core_hdr): #define as LHS varient.
> 	(xcoff64_core_p): Constify return_value variable.

I am hesitant to apply a patch which does not appear to be needed.

> -#define	core_hdr(abfd)		((struct core_dumpxx *)
> abfd->tdata.any)
> +#define	core_hdr(abfd)		(abfd->tdata.any)	/* gcc 4
> support */

Is this necessary.  You could just alter the use of core_hdr() in 
xcoff64_core_p() and leave the macro alone.

Cheers
   Nick