GDB 6.5.90 available for testing (GDB 6.6 pre-release)

GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Joel Brobecker]

Hello,

I have just finished creating the first release candidate for
GDB 6.6. It is available for download at the following location:

        ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-6.5.90.tar.bz2

A gzip'ed version is also available: gdb-6.4.90.tar.gz.

Please give it a test if you can and report any problems you might
find. If all goes well, this should be very close to what the GDB 6.6
release will be.

On behalf of all the GDB contributors, thank you!
-- 
Joel

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Markus Deuling]

Hallo,

Joel Brobecker schrieb:
> Hello,
> 
> I have just finished creating the first release candidate for
> GDB 6.6. It is available for download at the following location:
> 
>         ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-6.5.90.tar.bz2
> 
> A gzip'ed version is also available: gdb-6.4.90.tar.gz.
> 
> Please give it a test if you can and report any problems you might
> find. If all goes well, this should be very close to what the GDB 6.6
> release will be.
> 
> On behalf of all the GDB contributors, thank you!

I tried to build it on x86, FC5 with following error:

c1: warnings being treated as errors
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c: In Funktion 
»pascal_object_print_value_fields«:
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: Warnung: 
»tmp_obstack.alloc_failed« könnte in dieser Funktion uninitialisiert 
verwendet werden

<schnipp ... >

/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: Warnung: 
»tmp_obstack.chunk_size« könnte in dieser Funktion uninitialisiert 
verwendet werden
make[2]: *** [p-valprint.o] Fehler 1
make[2]: Leaving directory `/home/user/gdb/6.5.90/gdb-6.5.90/build/gdb'
make[1]: *** [all-gdb] Fehler 2
make[1]: Leaving directory `/home/user/gdb/6.5.90/gdb-6.5.90/build'
make: *** [all] Fehler 2
[user@host build]$


I checked out 6.6 branch and head some days ago, they build fine.


Regards,
Markus

-- 
Markus Deuling
GNU Toolchain for Linux on Cell BE
deuling@de.ibm.com

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Marc Kleine-Budde]

Joel Brobecker wrote:

> I have just finished creating the first release candidate for
> GDB 6.6. It is available for download at the following location:
> 
>         ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-6.5.90.tar.bz2
> 
> A gzip'ed version is also available: gdb-6.4.90.tar.gz.

> Please give it a test if you can and report any problems you might
> find. If all goes well, this should be very close to what the GDB 6.6
> release will be.

The problem with libtermcap resp. libncurses in a non default location 
still exists. See PR2175, PR2176 and 
http://sources.redhat.com/ml/gdb/2006-10/msg00234.html

This is a combined version of Kaz and my patch. Please consider applying 
or has the Makefile.tpl to be modified?

Marc

---
Index: gdb-6.5.90/Makefile.in
===================================================================
--- gdb-6.5.90.orig/Makefile.in
+++ gdb-6.5.90/Makefile.in
@@ -140,6 +140,7 @@ HOST_EXPORTS = \
  	$(BASE_EXPORTS) \
  	CC="$(CC)"; export CC; \
  	CFLAGS="$(CFLAGS)"; export CFLAGS; \
+	CPPFLAGS="$(CPPFLAGS)"; export CPPFLAGS; \
  	CONFIG_SHELL="$(SHELL)"; export CONFIG_SHELL; \
  	CXX="$(CXX)"; export CXX; \
  	CXXFLAGS="$(CXXFLAGS)"; export CXXFLAGS; \
@@ -288,8 +289,9 @@ STRIP = @STRIP@
  WINDRES = @WINDRES@

  CFLAGS = @CFLAGS@
-LDFLAGS =
+LDFLAGS = @LDFLAGS@
  LIBCFLAGS = $(CFLAGS)
+CPPFLAGS = @CPPFLAGS@
  CXXFLAGS = @CXXFLAGS@
  LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates
  PICFLAG =
Index: gdb-6.5.90/gdb/Makefile.in
===================================================================
--- gdb-6.5.90.orig/gdb/Makefile.in
+++ gdb-6.5.90/gdb/Makefile.in
@@ -352,7 +352,7 @@ CXXFLAGS = -g -O

  # INTERNAL_CFLAGS is the aggregate of all other *CFLAGS macros.
  INTERNAL_CFLAGS_BASE = \
-	$(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
+	$(CPPFLAGS) $(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
  	$(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) \
  	$(BFD_CFLAGS) $(INCLUDE_CFLAGS) \
  	$(INTL_CFLAGS) $(ENABLE_CFLAGS) $(INTERNAL_CPPFLAGS)
@@ -362,6 +362,8 @@ INTERNAL_CFLAGS = $(INTERNAL_WARN_CFLAGS
  # LDFLAGS is specifically reserved for setting from the command line
  # when running make.
  LDFLAGS = @LDFLAGS@
+CPPFLAGS = @CPPFLAGS@
+

  # Profiling options need to go here to work.
  # I think it's perfectly reasonable for a user to set -pg in CFLAGS
@@ -441,6 +443,7 @@ FLAGS_TO_PASS = \
  	"AR_FLAGS=$(AR_FLAGS)" \
  	"CC=$(CC)" \
  	"CFLAGS=$(CFLAGS)" \
+	"CPPFLAGS=$(CPPFLAGS)" \
  	"CXX=$(CXX)" \
  	"CXXFLAGS=$(CXXFLAGS)" \
  	"DLLTOOL=$(DLLTOOL)" \
@@ -500,6 +503,7 @@ TARGET_FLAGS_TO_PASS = \
  	'CC=$$(CC_FOR_TARGET)' \
  	"CC_FOR_TARGET=$(CC_FOR_TARGET)" \
  	"CFLAGS=$(CFLAGS)" \
+	"CPPFLAGS=$(CPPFLAGS)" \
  	'CXX=$$(CXX_FOR_TARGET)' \
  	"CXX_FOR_TARGET=$(CXX_FOR_TARGET)" \
  	"CXXFLAGS=$(CXXFLAGS)" \


-- 
  Dipl.-Ing. Marc Kleine-Budde | http://www.pengutronix.de
   Pengutronix - Linux Solutions for Science and Industry
     Handelsregister: Amtsgericht Hildesheim, HRA 2686
       Hannoversche Str. 2, 31134 Hildesheim, Germany
     Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Joel Brobecker]

> I tried to build it on x86, FC5 with following error:

Thanks for trying it out...

> c1: warnings being treated as errors
> /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c: In Funktion 
> »pascal_object_print_value_fields«:
> /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: Warnung: 
> »tmp_obstack.alloc_failed« könnte in dieser Funktion uninitialisiert 
> verwendet werden
> 
> <schnipp ... >
> 
> /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: Warnung: 
> »tmp_obstack.chunk_size« könnte in dieser Funktion uninitialisiert 
> verwendet werden
> make[2]: *** [p-valprint.o] Fehler 1
> make[2]: Leaving directory `/home/user/gdb/6.5.90/gdb-6.5.90/build/gdb'
> make[1]: *** [all-gdb] Fehler 2
> make[1]: Leaving directory `/home/user/gdb/6.5.90/gdb-6.5.90/build'
> make: *** [all] Fehler 2
> [user@host build]$

I don't speak German, so if you could set your environment to C,
that would help me understand the source of the problem.

A workaround for you is to build with --disable-werror.

> I checked out 6.6 branch and head some days ago, they build fine.

So we just need to isolate the patch from head that avoids the warning.

-- 
Joel

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Daniel Jacobowitz]

On Mon, Dec 04, 2006 at 10:21:08AM -0800, Joel Brobecker wrote:
> > I checked out 6.6 branch and head some days ago, they build fine.
> 
> So we just need to isolate the patch from head that avoids the warning.

Maybe it's a different compiler in use?  I know that some versions of
4.0.x warn about this, but 4.1.x do not.  HJ posted a relevant patch
last week.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Joel Brobecker]

> The problem with libtermcap resp. libncurses in a non default location 
> still exists. See PR2175, PR2176 and 
> http://sources.redhat.com/ml/gdb/2006-10/msg00234.html
> 
> This is a combined version of Kaz and my patch. Please consider applying 
> or has the Makefile.tpl to be modified?

Thanks for the feedback. Unfortunately, there is not enough context in
what you provided to understand what happened. It looks like your patch
was never reviewed (only from the pieces I have, but I may be wrong).
My suggestion, if you'd like this to be included, is to post again
the patch on gdb-patches, and ask for review. Use the patch tracker
if necessary to make sure it doesn't get overlooked (but this does
NOT guaranty fast review).

Once it is head, then we can discuss whether we want this patch
in the branch or not.

-- 
Joel

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Ulrich Weigand]

Joel Brobecker wrote:

> I have just finished creating the first release candidate for
> GDB 6.6. It is available for download at the following location:
> 
>         ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-6.5.90.tar.bz2
> 
> A gzip'ed version is also available: gdb-6.4.90.tar.gz.
> 
> Please give it a test if you can and report any problems you might
> find. If all goes well, this should be very close to what the GDB 6.6
> release will be.

Looking OK on s390(x)-ibm-linux:
http://sources.redhat.com/ml/gdb-testers/2006-q4/msg00020.html
http://sources.redhat.com/ml/gdb-testers/2006-q4/msg00021.html
(quite some regressions in there are actually caused by a change
in execution environment to glibc 2.4 and 128-bit long double ...)

and also on spu-elf:
http://sources.redhat.com/ml/gdb-testers/2006-q4/msg00022.html
(the store.exp FAILs are expected at this point).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Markus Deuling]

Hello Joel,

Joel Brobecker schrieb:
>> I tried to build it on x86, FC5 with following error:
> 
> Thanks for trying it out...
> 
>> c1: warnings being treated as errors
>> /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c: In Funktion 
>> »pascal_object_print_value_fields«:
>> /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: Warnung: 
>> »tmp_obstack.alloc_failed« könnte in dieser Funktion uninitialisiert 
>> verwendet werden
>>
>> <schnipp ... >
>>
>> /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: Warnung: 
>> »tmp_obstack.chunk_size« könnte in dieser Funktion uninitialisiert 
>> verwendet werden
>> make[2]: *** [p-valprint.o] Fehler 1
>> make[2]: Leaving directory `/home/user/gdb/6.5.90/gdb-6.5.90/build/gdb'
>> make[1]: *** [all-gdb] Fehler 2
>> make[1]: Leaving directory `/home/user/gdb/6.5.90/gdb-6.5.90/build'
>> make: *** [all] Fehler 2
>> [user@host build]$
> 
> I don't speak German, so if you could set your environment to C,
> that would help me understand the source of the problem.
> 
> A workaround for you is to build with --disable-werror.
> 
>> I checked out 6.6 branch and head some days ago, they build fine.
> 
> So we just need to isolate the patch from head that avoids the warning.
> 

1) Environment is x86, Fedora Core 5, gcc (GCC) 4.1.1 20060525 (Red Hat 
4.1.1-1)


2) I rebuild it with --disable-werror and it works fine. Testsuite looks 
good:
http://sources.redhat.com/ml/gdb-testers/2006-q4/msg00023.html


3) I switched the environment so you get the error msg in english. Sorry 
for the german :-) So this is for x86 without --disable-werror

/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c: In function 
'pascal_object_print_value_fields':
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.alloc_failed' may be used uninitialized in this function
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.maybe_empty_object' may be used uninitialized in this function
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.use_extra_arg' may be used uninitialized in this function
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.extra_arg' may be used uninitialized in this function
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.freefun' may be used uninitialized in this function
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.chunkfun' may be used uninitialized in this function
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.alignment_mask' may be used uninitialized in this function
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.temp' may be used uninitialized in this function
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.chunk_limit' may be used uninitialized in this function
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.next_free' may be used uninitialized in this function
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.object_base' may be used uninitialized in this function
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.chunk' may be used uninitialized in this function
/home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 
'tmp_obstack.chunk_size' may be used uninitialized in this function
make[2]: *** [p-valprint.o] Error 1
make[2]: Leaving directory `/home/user/gdb/6.5.90/gdb-6.5.90/build_werr/gdb'
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory `/home/user/gdb/6.5.90/gdb-6.5.90/build_werr'
make: *** [all] Error 2


Regards,
Markus

-- 
Markus Deuling
GNU Toolchain for Linux on Cell BE
deuling@de.ibm.com

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Markus Deuling]

Hi Joel,

Joel Brobecker schrieb:
> Hello,
> 
> I have just finished creating the first release candidate for
> GDB 6.6. It is available for download at the following location:
> 
>         ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-6.5.90.tar.bz2
> 
> A gzip'ed version is also available: gdb-6.4.90.tar.gz.
> 
> Please give it a test if you can and report any problems you might
> find. If all goes well, this should be very close to what the GDB 6.6
> release will be.
> 
> On behalf of all the GDB contributors, thank you!

I build it on powerpc without problems. I think there are some 
regressions. Does not look that good at all.

Results:
http://sources.redhat.com/ml/gdb-testers/2006-q4/msg00024.html


Regards,
Markus

-- 
Markus Deuling
GNU Toolchain for Linux on Cell BE
deuling@de.ibm.com

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Joel Brobecker]

> I build it on powerpc without problems. I think there are some 
> regressions. Does not look that good at all.
> 
> Results:
> http://sources.redhat.com/ml/gdb-testers/2006-q4/msg00024.html

Did you compare that with the results obtained with GDB 6.5?
That would be an interesting datapoint.

-- 
Joel

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Joel Brobecker]

> 3) I switched the environment so you get the error msg in english. Sorry 
> for the german :-) So this is for x86 without --disable-werror

(no worries about the German, thanks for reposting the messages
in English :-)

I must say I do not understand why it builds fine with head,
because I saw the patch that Daniel refered to (from H.J Lu),
and it should fix your warnings. However, it hasn't been checked in
yet! But it doesn't really matter as far as I am concerned, because...

I think all future releases will be provided so that -Werror is removed
by default, so we don't need to take at the code level. The only thing
I need to do is to set --disable-werror by default. Will do momentarily.

Thanks for reporting this!

-- 
Joel

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Jim Blandy]

Here's the patch I've been using for this.  It'd be better to rework
the way those functions use those obstacks, but...

2006-12-05  Jim Blandy  <jimb@codesourcery.com>

      * cp-valprint.c (cp_print_value_fields, cp_print_value):
      Initialize tmp_obstack, to avoid warnings.
      * p-valprint.c (pascal_object_print_value_fields)
      (pascal_object_print_value): Same.
  
diff -rN -u old-lval/gdb/cp-valprint.c new-lval/gdb/cp-valprint.c
--- gdb/cp-valprint.c	2006-12-05 11:11:42.000000000 -0800
+++ gdb/cp-valprint.c	2006-12-05 11:11:43.000000000 -0800
@@ -269,6 +269,9 @@
   char *last_dont_print = obstack_next_free (&dont_print_statmem_obstack);
   int fields_seen = 0;
 
+  /* This isn't necessary, but it avoids compiler warnings.  */
+  obstack_init (&tmp_obstack);
+
   CHECK_TYPEDEF (type);
 
   fprintf_filtered (stream, "{");
@@ -531,6 +534,9 @@
   int thisoffset;
   struct type *thistype;
 
+  /* This isn't necessary, but it avoids compiler warnings.  */
+  obstack_init (&tmp_obstack);
+
   if (dont_print_vb == 0)
     {
       /* If we're at top level, carve out a completely fresh
diff -rN -u old-lval/gdb/p-valprint.c new-lval/gdb/p-valprint.c
--- gdb/p-valprint.c	2006-12-05 11:11:42.000000000 -0800
+++ gdb/p-valprint.c	2006-12-05 11:11:44.000000000 -0800
@@ -756,6 +756,9 @@
   struct obstack tmp_obstack;
   char *last_dont_print = obstack_next_free (&dont_print_statmem_obstack);
 
+  /* This isn't necessary, but it avoids compiler warnings.  */
+  obstack_init (&tmp_obstack);
+
   CHECK_TYPEDEF (type);
 
   fprintf_filtered (stream, "{");
@@ -927,6 +930,9 @@
   = (struct type **) obstack_next_free (&dont_print_vb_obstack);
   int i, n_baseclasses = TYPE_N_BASECLASSES (type);
 
+  /* This isn't necessary, but it avoids compiler warnings.  */
+  obstack_init (&tmp_obstack);
+
   if (dont_print_vb == 0)
     {
       /* If we're at top level, carve out a completely fresh

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Daniel Jacobowitz]

On Tue, Dec 05, 2006 at 11:12:59AM -0800, Jim Blandy wrote:
> 
> Here's the patch I've been using for this.  It'd be better to rework
> the way those functions use those obstacks, but...

I might be mistaken, but I think calling obstack_init here is a memory
leak.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[H. J. Lu]

On Tue, Dec 05, 2006 at 11:12:59AM -0800, Jim Blandy wrote:
> 
> Here's the patch I've been using for this.  It'd be better to rework
> the way those functions use those obstacks, but...
> 
> 2006-12-05  Jim Blandy  <jimb@codesourcery.com>
> 
>       * cp-valprint.c (cp_print_value_fields, cp_print_value):
>       Initialize tmp_obstack, to avoid warnings.
>       * p-valprint.c (pascal_object_print_value_fields)
>       (pascal_object_print_value): Same.
>   

What is wrong with

http://sources.redhat.com/ml/gdb-patches/2006-12/msg00008.html


H.J.

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Mark Kettenis]

>
>  Here's the patch I've been using for this.  It'd be better to rework
>  the way those functions use those obstacks, but...
>
>  2006-12-05  Jim Blandy  <jimb@codesourcery.com>
>
>        * cp-valprint.c (cp_print_value_fields, cp_print_value):
>        Initialize tmp_obstack, to avoid warnings.
>        * p-valprint.c (pascal_object_print_value_fields)
>        (pascal_object_print_value): Same.

This is silly, at least if they are really unecessary.  It's a bug in GCC
and should be fixed.  I mean, GCC should get better at detecting this sort
of things; not give more false positives.

Markus, can you file a GCC bug report for this?

>
>  diff -rN -u old-lval/gdb/cp-valprint.c new-lval/gdb/cp-valprint.c
>  --- gdb/cp-valprint.c	2006-12-05 11:11:42.000000000 -0800
>  +++ gdb/cp-valprint.c	2006-12-05 11:11:43.000000000 -0800
>  @@ -269,6 +269,9 @@
>     char *last_dont_print = obstack_next_free
>  (&dont_print_statmem_obstack);
>     int fields_seen = 0;
>
>  +  /* This isn't necessary, but it avoids compiler warnings.  */
>  +  obstack_init (&tmp_obstack);
>  +
>     CHECK_TYPEDEF (type);
>
>     fprintf_filtered (stream, "{");
>  @@ -531,6 +534,9 @@
>     int thisoffset;
>     struct type *thistype;
>
>  +  /* This isn't necessary, but it avoids compiler warnings.  */
>  +  obstack_init (&tmp_obstack);
>  +
>     if (dont_print_vb == 0)
>       {
>         /* If we're at top level, carve out a completely fresh
>  diff -rN -u old-lval/gdb/p-valprint.c new-lval/gdb/p-valprint.c
>  --- gdb/p-valprint.c	2006-12-05 11:11:42.000000000 -0800
>  +++ gdb/p-valprint.c	2006-12-05 11:11:44.000000000 -0800
>  @@ -756,6 +756,9 @@
>     struct obstack tmp_obstack;
>     char *last_dont_print = obstack_next_free
>  (&dont_print_statmem_obstack);
>
>  +  /* This isn't necessary, but it avoids compiler warnings.  */
>  +  obstack_init (&tmp_obstack);
>  +
>     CHECK_TYPEDEF (type);
>
>     fprintf_filtered (stream, "{");
>  @@ -927,6 +930,9 @@
>     = (struct type **) obstack_next_free (&dont_print_vb_obstack);
>     int i, n_baseclasses = TYPE_N_BASECLASSES (type);
>
>  +  /* This isn't necessary, but it avoids compiler warnings.  */
>  +  obstack_init (&tmp_obstack);
>  +
>     if (dont_print_vb == 0)
>       {
>         /* If we're at top level, carve out a completely fresh
>
>

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Daniel Jacobowitz]

On Tue, Dec 05, 2006 at 10:36:20PM +0100, Mark Kettenis wrote:
> >
> >  Here's the patch I've been using for this.  It'd be better to rework
> >  the way those functions use those obstacks, but...
> >
> >  2006-12-05  Jim Blandy  <jimb@codesourcery.com>
> >
> >        * cp-valprint.c (cp_print_value_fields, cp_print_value):
> >        Initialize tmp_obstack, to avoid warnings.
> >        * p-valprint.c (pascal_object_print_value_fields)
> >        (pascal_object_print_value): Same.
> 
> This is silly, at least if they are really unecessary.  It's a bug in GCC
> and should be fixed.  I mean, GCC should get better at detecting this sort
> of things; not give more false positives.
> 
> Markus, can you file a GCC bug report for this?

I'm pretty sure the GCC bug was fixed in later versions of 4.1.x
already.  At least, my compiler no longer warns about it.  But I have
no idea how reliable that is - I can't see any vaguely efficient way to
compute this.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> On Tue, Dec 05, 2006 at 11:12:59AM -0800, Jim Blandy wrote:
>> 
>> Here's the patch I've been using for this.  It'd be better to rework
>> the way those functions use those obstacks, but...
>
> I might be mistaken, but I think calling obstack_init here is a memory
> leak.

[reads obstack code]  You're right.  Jeez.

H.J.'s patch looks okay to me.

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Markus Deuling]

Hi Joel,

Joel Brobecker schrieb:
>> I build it on powerpc without problems. I think there are some 
>> regressions. Does not look that good at all.
>>
>> Results:
>> http://sources.redhat.com/ml/gdb-testers/2006-q4/msg00024.html
> 
> Did you compare that with the results obtained with GDB 6.5?
> That would be an interesting datapoint.
> 

I compared it with vanilla GDB 6.5 on powerpc with nearly the same results:

http://sourceware.org/ml/gdb-testers/2006-q4/msg00025.html

Regards,
Markus

-- 
Markus Deuling
GNU Toolchain for Linux on Cell BE
deuling@de.ibm.com

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Markus Deuling]

Hi Mark,

Mark Kettenis schrieb:
>>  Here's the patch I've been using for this.  It'd be better to rework
>>  the way those functions use those obstacks, but...
>>
>>  2006-12-05  Jim Blandy  <jimb@codesourcery.com>
>>
>>        * cp-valprint.c (cp_print_value_fields, cp_print_value):
>>        Initialize tmp_obstack, to avoid warnings.
>>        * p-valprint.c (pascal_object_print_value_fields)
>>        (pascal_object_print_value): Same.
> 
> This is silly, at least if they are really unecessary.  It's a bug in GCC
> and should be fixed.  I mean, GCC should get better at detecting this sort
> of things; not give more false positives.
> 
> Markus, can you file a GCC bug report for this?

I opened a GCC bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30086


Regards,
Markus

-- 
Markus Deuling
GNU Toolchain for Linux on Cell BE
deuling@de.ibm.com

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Joel Brobecker]

> >>Results:
> >>http://sources.redhat.com/ml/gdb-testers/2006-q4/msg00024.html
> >
> >Did you compare that with the results obtained with GDB 6.5?
> >That would be an interesting datapoint.
> >
> 
> I compared it with vanilla GDB 6.5 on powerpc with nearly the same results:
> 
> http://sourceware.org/ml/gdb-testers/2006-q4/msg00025.html

Thanks. It looks like there has not been any degradation in the quality
of that port, which is good. If you have some time in the future,
perhaps you can help fixing the issues that the testsuite is revealing
and improve the next release? ;-)

-- 
Joel

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Markus Deuling]

Joel Brobecker schrieb:
>>>> Results:
>>>> http://sources.redhat.com/ml/gdb-testers/2006-q4/msg00024.html
>>> Did you compare that with the results obtained with GDB 6.5?
>>> That would be an interesting datapoint.
>>>
>> I compared it with vanilla GDB 6.5 on powerpc with nearly the same results:
>>
>> http://sourceware.org/ml/gdb-testers/2006-q4/msg00025.html
> 
> Thanks. It looks like there has not been any degradation in the quality
> of that port, which is good. If you have some time in the future,
> perhaps you can help fixing the issues that the testsuite is revealing
> and improve the next release? ;-)
> 

I will give it a try :-)

Regards,
Markus

-- 
Markus Deuling
GNU Toolchain for Linux on Cell BE
deuling@de.ibm.com

Re: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Markus Deuling]

Hello all,

Markus Deuling schrieb:
> Hi Mark,
> 
> Mark Kettenis schrieb:
>>>  Here's the patch I've been using for this.  It'd be better to rework
>>>  the way those functions use those obstacks, but...
>>>
>>>  2006-12-05  Jim Blandy  <jimb@codesourcery.com>
>>>
>>>        * cp-valprint.c (cp_print_value_fields, cp_print_value):
>>>        Initialize tmp_obstack, to avoid warnings.
>>>        * p-valprint.c (pascal_object_print_value_fields)
>>>        (pascal_object_print_value): Same.
>>
>> This is silly, at least if they are really unecessary.  It's a bug in GCC
>> and should be fixed.  I mean, GCC should get better at detecting this 
>> sort
>> of things; not give more false positives.
>>
>> Markus, can you file a GCC bug report for this?
> 
> I opened a GCC bugzilla:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30086

the GCC Bugzilla I opened was marked duplicated. This is the current 
bugzilla for this topic:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035


Regards,
Markus

-- 
Markus Deuling
GNU Toolchain for Linux on Cell BE
deuling@de.ibm.com

RE: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

[Kaz Kylheku]

Joel Brobecker wrote: 
> > The problem with libtermcap resp. libncurses in a non 
> default location 
> > still exists. See PR2175, PR2176 and 
> > http://sources.redhat.com/ml/gdb/2006-10/msg00234.html
> > 
> > This is a combined version of Kaz and my patch. Please 
> consider applying 
> > or has the Makefile.tpl to be modified?
> 
> Thanks for the feedback. Unfortunately, there is not enough context in
> what you provided to understand what happened. It looks like 
> your patch
> was never reviewed (only from the pieces I have, but I may be wrong).
> My suggestion, if you'd like this to be included, is to post again
> the patch on gdb-patches, and ask for review. Use the patch tracker
> if necessary to make sure it doesn't get overlooked (but this does
> NOT guaranty fast review).
> 
> Once it is head, then we can discuss whether we want this patch
> in the branch or not.
> 
> -- 
> Joel

I no longer care about the patch, because I solved the problem
differently, for other reasons.

I still think that if GDB's has the apparent suport locating libraries
in non-default locations, then that support should work. Or else it
should be dropped. I.e. don't allow a variable to be configured in the
top level configure, if the lower levels are going to ignore it.

The original problem was that I was installing libraries such as ncurses
into their own directories, so that I could easily make binary packages,
without having to extract the installed materials from the
cross-compiling toolchain sysroot.

I quickly found out that gdb couldn't be configured to find ncurses in a
nonstandard location and developed a patch, which turned out to be
nearly the same as Marc's.

But having libraries in nonstandard locations will cause problems in
general. Every time you build anything which depends on them, it will
have to be configured to find them, which means figuring out /how/ to
configure it to find them, and debugging it when that doesn't work.

The solution, for me, is to install ncurses (and indeed all libraries)
into two places: install it into the a directory from which  a package
is made, /and/ also install it into the cross-compiling toolchain's
sysroot. (I don't do this second step with a ``make install'' but rather
by selective recursive copying from the temporary install dir).

And so, I backed out my patch.

Note that I'm also preparing a prebuilt toolchain distribution with all
the libraries, header files and documentation.  So when a library
package is built and installed, a packaging step builds tarballs from
the install directory, and a toolchain install step copies materials
into the toolchain sysroot, making that library available for linking.
In this toolchain, I don't want to expose people to problems of locating
libraries. Linking ncurses should just be ``arch-prefix-gcc ... objects
... -lncurses''. But I still want a binary package of ncurses to install
on the target without having to extract the pieces from the toolchain
sysroot.