Re: some compile errors fo gdb-7.0.1

Re: some compile errors fo gdb-7.0.1

[Pedro Alves]

[moving from bug-gdb@gnu.org, patches go to gdb-patches@]

On Monday 15 February 2010 14:16:21, Harald Koenig wrote:
> Hi,
> 
> trying to compile gdb-7.0.1 on HP-UX, the hp cc complains about some problems in
> mi-main.c and breakpoint.c symfile.c
> 
>        cc: "/soft/os/gdb/gdb-7.0.1/gdb-7.0.1/gdb/mi/mi-main.c", line 176: error 1610: Attempting to return value from function of type void.
>        cc: "/soft/os/gdb/gdb-7.0.1/gdb-7.0.1/gdb/breakpoint.c", line 8275: error 1000: Unexpected symbol: "}".
>        cc: "/soft/os/gdb/gdb-7.0.1/gdb-7.0.1/gdb/symfile.c", line 4036: error 1649: Illegal integer-pointer combination for >.
> 
> obvious patches attached...

Thanks.  I've applied it to mainline, as below, after
running the testsuite with it and finding on regressions.
The breakpoint.c hunk was no longer necessary, the same fix
had already been applied since 7 was released.

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.

-- 
Pedro Alves

2010-02-18  Harald Koenig  <H.Koenig@science-computing.de>

	* mi/mi-main.c (mi_cmd_exec_jump): Drop unneeded `return'.
	* symfile.c (symfile_map_offsets_to_segments): Fix assertion.

---
 gdb/mi/mi-main.c |    2 +-
 gdb/symfile.c    |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Index: src/gdb/mi/mi-main.c
===================================================================
--- src.orig/gdb/mi/mi-main.c	2010-02-17 19:41:35.000000000 +0000
+++ src/gdb/mi/mi-main.c	2010-02-18 18:13:08.000000000 +0000
@@ -190,7 +190,7 @@ void
 mi_cmd_exec_jump (char *args, char **argv, int argc)
 {
   /* FIXME: Should call a libgdb function, not a cli wrapper.  */
-  return mi_execute_async_cli_command ("jump", argv, argc);
+  mi_execute_async_cli_command ("jump", argv, argc);
 }
  
 static int
Index: src/gdb/symfile.c
===================================================================
--- src.orig/gdb/symfile.c	2010-02-17 22:01:03.000000000 +0000
+++ src/gdb/symfile.c	2010-02-18 18:13:08.000000000 +0000
@@ -3715,7 +3715,7 @@ symfile_map_offsets_to_segments (bfd *ab
 
   /* It doesn't make sense to call this function unless you have some
      segment base addresses.  */
-  gdb_assert (segment_bases > 0);
+  gdb_assert (num_segment_bases > 0);
 
   /* If we do not have segment mappings for the object file, we
      can not relocate it by segments.  */

Re: some compile errors fo gdb-7.0.1

[Harald Koenig]

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

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 ?!   

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).

-------------------------------------------------------------------------------
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...

-------------------------------------------------------------------------------
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
(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
./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...
-------------------------------------------------------------------------------



Harald Koenig
-- 
"I hope to die                                      ___       _____
before I *have* to use Microsoft Word.",           0--,|    /OOOOOOO\
Donald E. Knuth, 02-Oct-2001 in Tuebingen.        <_/  /  /OOOOOOOOOOO\
                                                    \  \/OOOOOOOOOOOOOOO\
                                                      \ OOOOOOOOOOOOOOOOO|//
Harald Koenig                                          \/\/\/\/\/\/\/\/\/
science+computing ag                                    //  /     \\  \
koenig@science-computing.de                            ^^^^^       ^^^^^
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


[-- Attachment #2: varobj.c.diff --]
[-- Type: text/plain, Size: 2021 bytes --]

Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.154
diff -u -r1.154 varobj.c
--- varobj.c	20 Jan 2010 06:36:38 -0000	1.154
+++ varobj.c	23 Feb 2010 14:15:10 -0000
@@ -1700,7 +1700,8 @@
 
   if (!(*varp)->root->is_valid)
     {
-      varobj_update_result r = {*varp};
+      varobj_update_result r = {0};
+      r.varobj = *varp;
       r.status = VAROBJ_INVALID;
       VEC_safe_push (varobj_update_result, result, &r);
       return result;
@@ -1708,7 +1709,8 @@
 
   if ((*varp)->root->rootvar == *varp)
     {
-      varobj_update_result r = {*varp};
+      varobj_update_result r = {0};
+      r.varobj = varp;
       r.status = VAROBJ_IN_SCOPE;
 
       /* Update the root variable. value_of_root can return NULL
@@ -1738,7 +1740,8 @@
     }
   else
     {
-      varobj_update_result r = {*varp};
+      varobj_update_result r = {0};
+      r.varobj = varp;
       VEC_safe_push (varobj_update_result, stack, &r);
     }
 
@@ -1815,7 +1818,8 @@
 	      for (i = VEC_length (varobj_p, changed) - 1; i >= 0; --i)
 		{
 		  varobj_p tmp = VEC_index (varobj_p, changed, i);
-		  varobj_update_result r = {tmp};
+		  varobj_update_result r = {0};
+		  r.varobj = tmp;
 		  r.changed = 1;
 		  r.value_installed = 1;
 		  VEC_safe_push (varobj_update_result, stack, &r);
@@ -1825,7 +1829,8 @@
 		  varobj_p tmp = VEC_index (varobj_p, unchanged, i);
 	      	  if (!tmp->frozen)
 	      	    {
-	      	      varobj_update_result r = {tmp};
+	      	      varobj_update_result r = {0};
+		      r.varobj = tmp;
 	      	      r.value_installed = 1;
 	      	      VEC_safe_push (varobj_update_result, stack, &r);
 	      	    }
@@ -1852,7 +1857,8 @@
 	  /* Child may be NULL if explicitly deleted by -var-delete.  */
 	  if (c != NULL && !c->frozen)
 	    {
-	      varobj_update_result r = {c};
+	      varobj_update_result r = {0};
+	      r.varobj = c;
 	      VEC_safe_push (varobj_update_result, stack, &r);
 	    }
 	}

[-- Attachment #3: c-exp.y.diff --]
[-- Type: text/plain, Size: 400 bytes --]

Index: c-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/c-exp.y,v
retrieving revision 1.71
diff -u -r1.71 c-exp.y
--- c-exp.y	19 Feb 2010 20:22:03 -0000	1.71
+++ c-exp.y	23 Feb 2010 14:42:29 -0000
@@ -2295,7 +2295,7 @@
 typedef struct
 {
   int token;
-  union YYSTYPE value;
+  YYSTYPE value;
 } token_and_value;
 
 DEF_VEC_O (token_and_value);

Re: some compile errors fo gdb-7.0.1

[Harald Koenig]

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

one more small patch for AIX in config/mh-ppc-aix in case $CC includes spaces.

for some reason in older gdb version we needed CC='gcc -isystem /usr/include'
shows that quoting problem.  will test if this still is needed (read: what's 
the real problem and a better fix, iff still needed at alll).



Harald Koenig
-- 
"I hope to die                                      ___       _____
before I *have* to use Microsoft Word.",           0--,|    /OOOOOOO\
Donald E. Knuth, 02-Oct-2001 in Tuebingen.        <_/  /  /OOOOOOOOOOO\
                                                    \  \/OOOOOOOOOOOOOOO\
                                                      \ OOOOOOOOOOOOOOOOO|//
Harald Koenig                                          \/\/\/\/\/\/\/\/\/
science+computing ag                                    //  /     \\  \
koenig@science-computing.de                            ^^^^^       ^^^^^
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


[-- Attachment #2: mh-ppc-aix.diff --]
[-- Type: text/plain, Size: 486 bytes --]

Index: mh-ppc-aix
===================================================================
RCS file: /cvs/src/src/config/mh-ppc-aix,v
retrieving revision 1.3
diff -u -r1.3 mh-ppc-aix
--- mh-ppc-aix	16 Aug 2009 12:49:48 -0000	1.3
+++ mh-ppc-aix	23 Feb 2010 16:31:34 -0000
@@ -5,4 +5,4 @@
 # don't do it any more.
 BOOT_ADAFLAGS = -gnatapg
 BOOT_LDFLAGS = -Wl,-bbigtoc
-LDFLAGS = `case $(CC) in *gcc*) echo -Wl,-bbigtoc ;; esac;`
+LDFLAGS = `case "$(CC)" in *gcc*) echo -Wl,-bbigtoc ;; esac;`

Re: some compile errors fo gdb-7.0.1

[Pedro Alves]

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

Re: some compile errors fo gdb-7.0.1

[Harald Koenig]

Hi,

here is a problem report for break points on AIX 5.1 and 5.3.

first AIX 5.3:

if a program first runs in gdb without any break points and finished,
then it's not possible to set break a break point for the next run
(this is the same on AIX 5.1 too):


	# gdb a.out 
	GNU gdb (GDB) 7.1.50.20100222-cvs
	Reading symbols from a.out...done.
	(gdb) r 
	Starting program: a.out 
	hello
	
	Program exited normally.
	(gdb) b main
==>	Cannot access memory at address 0xf00d7530
	(gdb) q

with bogus address "0xf00d7530"


if there is a(ny) break point set for the 1st run things seem to work fine:

	# gdb a.out 
	GNU gdb (GDB) 7.1.50.20100222-cvs
	Reading symbols from a.out...done.
	(gdb) b main
	Breakpoint 1 at 0x100003c8: file hello.c, line 23.
	(gdb) r
	Starting program: a.out 
	
	Breakpoint 1, main (argc=1, argv=0x2ff22578, env=0x2ff22580) at hello.c:23
	23      main(int argc...
	(gdb) c
	Continuing.
	hello
	
	Program exited normally.
	(gdb) r
	Starting program: a.out 
	
	Breakpoint 1, main (argc...=1, argv=0x2ff22578, env=0x2ff22580) at hello.c:23
	23      main(int argc, ...
	(gdb) c
	Continuing.
	hello
	
	Program exited normally.
	(gdb) b main
	Note: breakpoint 1 also set at pc 0x100003c8.
	Breakpoint 2 at 0x100003c8: file hello.c, line 23.
	(gdb) r
	Starting program: a.out 
	
	Breakpoint 1, main (argc=1, argv=0x2ff22578, env=0x2ff22580) at hello.c:23
	23      main(int argc, ...
	(gdb) c
	Continuing.
	hello
	
	Program exited normally.
	(gdb) 



===============================================================================

on AIX 5.1 though setting a break point before the first run
only seems to work, but that break point is not functional for the 1st run:

	Reading symbols from a.out...done.
	(gdb) b main
	Breakpoint 1 at 0x100003c8: file hello.c, line 23.
	(gdb) i b
	Num     Type           Disp Enb Address    What
	1       breakpoint     keep y   0x100003c8 in main at hello.c:23
	(gdb) r
	Starting program: a.out 
==>	Error in re-setting breakpoint 1: Cannot access memory at address 0x0
==>	Error in re-setting breakpoint 1: Cannot access memory at address 0x0
	hello
	
	Program exited normally.
	(gdb) i b
	Num     Type           Disp Enb Address    What
	1       breakpoint     keep y   0x100003c8 in main at hello.c:23

and that break point doesn't function either in a 2nd run:

	(gdb) r
	Starting program: a.out 
	hello
	
	Program exited normally.


but if I add another bp to main (or another function) gdb starts to work "better";)

	(gdb) i b   
	Num     Type           Disp Enb Address    What
	1       breakpoint     keep n   0x100003c8 in main at hello.c:23
	(gdb) b main
	Note: breakpoint 1 (disabled) also set at pc 0x100003c8.
	Breakpoint 2 at 0x100003c8: file hello.c, line 23.
	(gdb) r
	Starting program: a.out 
	
	Breakpoint 2, main (argc=1, argv=0x2ff2248c, env=0x2ff22494) at hello.c:23
	23      main(int argc,...
	(gdb) i b
	Num     Type           Disp Enb Address    What
	1       breakpoint     keep n   0x100003c8 in main at hello.c:23
	2       breakpoint     keep y   0x100003c8 in main at hello.c:23
	        breakpoint already hit 1 time
	(gdb) c
	Continuing.
	hello
	
	Program exited normally.
	(gdb) r
	Starting program: a.out 
	
	Breakpoint 2, main (argc=1, argv=0x2ff2248c, env=0x2ff22494) at hello.c:23
	23      main(int argc,...
	(gdb) c
	Continuing.
	hello
	
	Program exited normally.
	(gdb) 


any thoughts about that breakpoint weirdnes son AIX ?!?



right now I'm trying to build gdb on AIX 6.1 which right now fails here

      "gdb-CVS-20100222/gdb/aix-thread.c", line 352.46: 1506-280 (W) Function argument assignment between types "int*" and "unsigned int*" is not allowed.

where the source reads like this -- hmmmmm....

  /* getthrds(3) isn't prototyped in any AIX 4.3.3 #include file.  */
  extern int getthrds (pid_t, struct thrdsinfo64 *,
                       int, pthdb_tid_t *, int);



but now I have to leave for today -- stay tuned ;-))

Harald Koenig
-- 
"I hope to die                                      ___       _____
before I *have* to use Microsoft Word.",           0--,|    /OOOOOOO\
Donald E. Knuth, 02-Oct-2001 in Tuebingen.        <_/  /  /OOOOOOOOOOO\
                                                    \  \/OOOOOOOOOOOOOOO\
                                                      \ OOOOOOOOOOOOOOOOO|//
Harald Koenig                                          \/\/\/\/\/\/\/\/\/
science+computing ag                                    //  /     \\  \
koenig@science-computing.de                            ^^^^^       ^^^^^
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 

Re: some compile errors fo gdb-7.0.1

[Harald Koenig]

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

On Feb 23, Harald Koenig wrote:

> right now I'm trying to build gdb on AIX 6.1 which right now fails here
> 
>       "gdb-CVS-20100222/gdb/aix-thread.c", line 352.46: 1506-280 (W) Function argument assignment between types "int*" and "unsigned int*" is not allowed.
> 
> where the source reads like this -- hmmmmm....
> 
>   /* getthrds(3) isn't prototyped in any AIX 4.3.3 #include file.  */
>   extern int getthrds (pid_t, struct thrdsinfo64 *,
>                        int, pthdb_tid_t *, int);

with the attached patch AIX 6.1 builds fine, and 5.1 still does so....
(_AIX51 is defined in 5.2/5.3 too!  I've not tested 5.0 though which is 
why I don't check _AIX50 which is defined in 5.1-5.3 too).

but:  6.1 has the same break point problems as 5.3:

- with no breakpoint before 1st run, break points can't be set later at all

- otherwise break points seem to work




Harald Koenig
-- 
"I hope to die                                      ___       _____
before I *have* to use Microsoft Word.",           0--,|    /OOOOOOO\
Donald E. Knuth, 02-Oct-2001 in Tuebingen.        <_/  /  /OOOOOOOOOOO\
                                                    \  \/OOOOOOOOOOOOOOO\
                                                      \ OOOOOOOOOOOOOOOOO|//
Harald Koenig                                          \/\/\/\/\/\/\/\/\/
science+computing ag                                    //  /     \\  \
koenig@science-computing.de                            ^^^^^       ^^^^^
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


[-- Attachment #2: aix-thread.c.diff --]
[-- Type: text/plain, Size: 573 bytes --]

Index: aix-thread.c
===================================================================
RCS file: /cvs/src/src/gdb/aix-thread.c,v
retrieving revision 1.72
diff -u -r1.72 aix-thread.c
--- aix-thread.c	1 Jan 2010 07:31:29 -0000	1.72
+++ aix-thread.c	24 Feb 2010 12:46:26 -0000
@@ -647,9 +647,11 @@
   pthdb_tid_t ktid = 0;
   int result = 0;
 
+#if !defined(_AIX51) && !defined(_AIX61)
   /* getthrds(3) isn't prototyped in any AIX 4.3.3 #include file.  */
   extern int getthrds (pid_t, struct thrdsinfo64 *, 
 		       int, pthdb_tid_t *, int);
+#endif
 
   while (1)
   {

Build errors on AIX

[Pedro Alves]

[removing bug-gdb@]

On Wednesday 24 February 2010 12:51:36, Harald Koenig wrote:
> On Feb 23, Harald Koenig wrote:
> 
> > right now I'm trying to build gdb on AIX 6.1 which right now fails here
> > 
> >       "gdb-CVS-20100222/gdb/aix-thread.c", line 352.46: 1506-280 (W) Function argument assignment between types "int*" and "unsigned int*" is not allowed.
                                                    ^^^^^^

How does one read that?  line 352, column 46?  On my sources,
352 has:

352:	  if (!ptrace32 (PTT_READ_GPRS, tid, gprs32, 0, NULL))
353:	    memset (gprs32, 0, sizeof (gprs32));

> > where the source reads like this -- hmmmmm....
> > 
> >   /* getthrds(3) isn't prototyped in any AIX 4.3.3 #include file.  */
> >   extern int getthrds (pid_t, struct thrdsinfo64 *,
> >                        int, pthdb_tid_t *, int);
> 

Anyway, ignoring line numbers, what's the compiler complaining about?
Is it the signness of pthdb_tid_t that is wrong?

> with the attached patch AIX 6.1 builds fine, and 5.1 still does so....
> (_AIX51 is defined in 5.2/5.3 too!  I've not tested 5.0 though which is 
> why I don't check _AIX50 which is defined in 5.1-5.3 too).

It would perhaps be better to autoconf the getthrds declaration being
present, here, in gdb/configure.ac:

   aix*)
      AC_MSG_CHECKING(for AiX thread debugging library)
      AC_CACHE_VAL(gdb_cv_have_aix_thread_debug,
                   [AC_TRY_COMPILE([#include <sys/pthdebug.h>],
                                   [#ifndef PTHDB_VERSION_3
                                    #error
                                    #endif],
                                   gdb_cv_have_aix_thread_debug=yes,
                                   gdb_cv_have_aix_thread_debug=no)])
      AC_MSG_RESULT($gdb_cv_have_aix_thread_debug)
      if test $gdb_cv_have_aix_thread_debug = yes; then
         CONFIG_SRCS="${CONFIG_SRCS} aix-thread.c"
         CONFIG_OBS="${CONFIG_OBS} aix-thread.o"
         CONFIG_LDFLAGS="${CONFIG_LDFLAGS} -lpthdebug"
      fi
      ;;
   esac

But I really don't know much about AIX.  Joel?  What do you
think?  You seem to be one of that last that touched
this `getthrds' bit of code.  :-)

> but:  6.1 has the same break point problems as 5.3:
> 
> - with no breakpoint before 1st run, break points can't be set later at all
> 
> - otherwise break points seem to work

I can't really guess exactly what's going on here.  AIX/RS6000
is probably the port that most needs love of all the supported
ports.  E.g, I wouldn't be surprised if recent changes like PIE
or multi-program support and the revamping around these broke
this port, for it does things in non-standard ways.  These
commands may offer some clues:

 "(gdb) maint info breakpoints"
 "(gdb) set debug infrun 1"
 "(gdb) set target infrun 1"

If you have an older gdb that works, I think we get to
debug the new gdb to try to track this down.

-- 
Pedro Alves

Re: Build errors on AIX

[Harald Koenig]

On Feb 24, Pedro Alves wrote:

> > >       "gdb-CVS-20100222/gdb/aix-thread.c", line 352.46: 1506-280 (W) Function argument assignment between types "int*" and "unsigned int*" is not allowed.
>                                                     ^^^^^^
> 
> How does one read that?  line 352, column 46?  On my sources,

oops, cut'n'paste error from the log file -- sorry!

yes. that's a (W)arning in line 352, don't care;)

the real error msg was this one -- fix is in my last mail:

     "gdb-CVS-20100222/gdb/aix-thread.c", line 651.14: 1506-343 (S) Redeclaration of getthrds differs from previous declaration on line 904 of "/usr/include/procinfo.h".


> I can't really guess exactly what's going on here.  AIX/RS6000
> is probably the port that most needs love of all the supported
> ports.  E.g, I wouldn't be surprised if recent changes like PIE
> or multi-program support and the revamping around these broke
> this port, for it does things in non-standard ways.  These
> commands may offer some clues:
> 
>  "(gdb) maint info breakpoints"
>  "(gdb) set debug infrun 1"
>  "(gdb) set target infrun 1"

	(gdb) set target infrun 1
	Ambiguous set command "target infrun 1": target-async, target-charset, target-wide-charset.

so:
	(gdb) set debug infrun 1
	(gdb) r
	Starting program: a.out 
	infrun: proceed (addr=0xffffffff, signal=0, step=0)
	infrun: resume (step=0, signal=0), trap_expected=0
	hello
	infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
	infrun: target_wait (-1, status) =
	infrun:   356558 [process 356558],
	infrun:   status->kind = exited, status = 9
	infrun: infwait_normal_state
	infrun: TARGET_WAITKIND_EXITED
	
	Program exited with code 011.
	infrun: stop_stepping
	(gdb) maint info breakpoints
	Num     Type           Disp Enb Address    What
	-1      thread events  keep y   0xd04b37e8 <__pthread_init> inf 1
	(gdb) b main
	Cannot access memory at address 0xf0322508
	(gdb) maint info breakpoints
	Num     Type           Disp Enb Address    What
	-1      thread events  keep y   0xd04b37e8 <__pthread_init> inf 1
	(gdb) b main
	Cannot access memory at address 0xf0322508
	(gdb) 



and for AIX 5.1:

	gdb a.out 
	GNU gdb (GDB) 7.1.50.20100222-cvs
	Reading symbols from a.out...(no debugging symbols found)...done.
	(gdb) b main
	Breakpoint 1 at 0x1000039c
	(gdb) maint info breakpoints
	Num     Type           Disp Enb Address    What
	1       breakpoint     keep y   0x1000039c <main+32> inf 1
	(gdb) r
	Starting program: a.out 
	Error in re-setting breakpoint 1: Cannot access memory at address 0x0
	Error in re-setting breakpoint 1: Cannot access memory at address 0x0
	hello
	
	Program exited normally.
	(gdb) r
	Starting program: a.out 
	hello
	
	Program exited normally.
	(gdb) maint info breakpoints
	Num     Type           Disp Enb Address    What
	1       breakpoint     keep n   0x1000039c <main+32> inf 1
	-1      thread events  keep y   0xd0347e44 <__pthread_init> inf 1
	(gdb) r
	Starting program: a.out 
	hello
	
	Program exited normally.
	(gdb) b main
	Note: breakpoint 1 (disabled) also set at pc 0x1000039c.
	Breakpoint 2 at 0x1000039c
	(gdb) maint info breakpoints
	Num     Type           Disp Enb Address    What
	1       breakpoint     keep n   0x1000039c <main+32> inf 1
	-1      thread events  keep y   0xd0347e44 <__pthread_init> inf 1
	2       breakpoint     keep y   0x1000039c <main+32> inf 1
	(gdb) r
	Starting program: a.out 
	
	Breakpoint 2, 0x1000039c in main ()
	(gdb) 


ah, I just notice that bp #1 got disabled (likely because of that "Error in re-setting breakpoint 1: Cannot access memory at address 0x0").

instead of a 2nd "b main" it also works to enable #1 with "en b 1" ...


> If you have an older gdb that works, I think we get to
> debug the new gdb to try to track this down.

yes, our  gdb-6.8 binary works just fine for me on AIX 5.1++ ...


Harald Koenig
-- 
"I hope to die                                      ___       _____
before I *have* to use Microsoft Word.",           0--,|    /OOOOOOO\
Donald E. Knuth, 02-Oct-2001 in Tuebingen.        <_/  /  /OOOOOOOOOOO\
                                                    \  \/OOOOOOOOOOOOOOO\
                                                      \ OOOOOOOOOOOOOOOOO|//
Harald Koenig                                          \/\/\/\/\/\/\/\/\/
science+computing ag                                    //  /     \\  \
koenig@science-computing.de                            ^^^^^       ^^^^^
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 

Re: Build errors on AIX

[Joel Brobecker]

> It would perhaps be better to autoconf the getthrds declaration being
> present, here, in gdb/configure.ac:
[...]
> But I really don't know much about AIX.  Joel?  What do you
> think?  You seem to be one of that last that touched
> this `getthrds' bit of code.  :-)

Yep, I agree that this is the way to go. I checked on AIX 5.3,
this function is not declared in any of the /usr/include/*.h file.

> > but:  6.1 has the same break point problems as 5.3:
> > - with no breakpoint before 1st run, break points can't be set later at all
> > - otherwise break points seem to work

This is indeed very weird. I don't see any of that on our end.
I follow the AIX status relatively closely - even if we don't run
the AIX testsuite nightly, we run the AdaCore one every second day.
The AIX port should be in good shape!  You might want to try AdaCore's
sources to see if it makes any difference (we might have forgotten to
contribute a couple of patches), but I don't think so.

http://libre.adacore.com/libre/tools/more_resources/gdb-for-ada-snapshot/

This is what we call gdb-head at AdaCore, which include all of AdaCore's
changes while tracking the HEAD from the FSF tree.

-- 
Joel

Re: some compile errors fo gdb-7.0.1

[Joel Brobecker]

> one more small patch for AIX in config/mh-ppc-aix in case $CC includes
> spaces.  for some reason in older gdb version we needed CC='gcc
> -isystem /usr/include' shows that quoting problem.  will test if this
> still is needed (read: what's the real problem and a better fix, iff
> still needed at alll).

Your patch looks reasonable to me, but it is not relevant to GDB
specifically.  You need to send it to gcc-patches.

> Index: mh-ppc-aix
> ===================================================================
> RCS file: /cvs/src/src/config/mh-ppc-aix,v
> retrieving revision 1.3
> diff -u -r1.3 mh-ppc-aix
> --- mh-ppc-aix	16 Aug 2009 12:49:48 -0000	1.3
> +++ mh-ppc-aix	23 Feb 2010 16:31:34 -0000
> @@ -5,4 +5,4 @@
>  # don't do it any more.
>  BOOT_ADAFLAGS = -gnatapg
>  BOOT_LDFLAGS = -Wl,-bbigtoc
> -LDFLAGS = `case $(CC) in *gcc*) echo -Wl,-bbigtoc ;; esac;`
> +LDFLAGS = `case "$(CC)" in *gcc*) echo -Wl,-bbigtoc ;; esac;`


-- 
Joel