gdb-7.5 branch ready for first release?

gdb-7.5 branch ready for first release?

[Joel Brobecker]

Hello,

It looks like we no longer have any blocking issue with the 7.5 branch,
so perhaps we are ready to create the first release off that branch?

Please let me know if I should wait. Otherwise, I will try to create
the release early next week.

-- 
Joel

Re: gdb-7.5 branch ready for first release?

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> It looks like we no longer have any blocking issue with the 7.5 branch,
Joel> so perhaps we are ready to create the first release off that branch?

Joel> Please let me know if I should wait. Otherwise, I will try to create
Joel> the release early next week.

I would like to put in a few bug fixes that are pending comment:

    http://sourceware.org/ml/gdb-patches/2012-07/msg00800.html
    http://sourceware.org/ml/gdb-patches/2012-08/msg00029.html
    http://sourceware.org/ml/gdb-patches/2012-08/msg00074.html
    http://sourceware.org/ml/gdb-patches/2012-08/msg00117.html

I think these are all pretty safe.
For the most part they are due to be committed at the end of next week.

Tom

Re: gdb-7.5 branch ready for first release?

[Joel Brobecker]

I thought I had replied to this message, but it looks like I didn't.
Ooops!

> I would like to put in a few bug fixes that are pending comment:
> 
>     http://sourceware.org/ml/gdb-patches/2012-07/msg00800.html
>     http://sourceware.org/ml/gdb-patches/2012-08/msg00029.html
>     http://sourceware.org/ml/gdb-patches/2012-08/msg00074.html
>     http://sourceware.org/ml/gdb-patches/2012-08/msg00117.html

That would be fine, I think. I don't see us in a rush to release,
so we can wait an extra week. Let me know when they are in!

-- 
Joel

Re: gdb-7.5 branch ready for first release?

[Jan Kratochvil]

On Mon, 06 Aug 2012 03:41:48 +0200, Joel Brobecker wrote:
> > I would like to put in a few bug fixes that are pending comment:
[...]
> That would be fine, I think. I don't see us in a rush to release,
> so we can wait an extra week. Let me know when they are in!

As various fixes (and not just regression) get checked in plan to check in
also
	Re: [PATCH] refreshed patch for PR 11804 and PR 9904
	http://sourceware.org/ml/gdb-patches/2012-07/msg00797.html
(fix of gcore of RELRO executables)
It is a FAQ at least least on #gdb, fixed longterm in Fedora.

It just possibly dumps more pages which is safe (Fedora dumps all of them).


Regards,
Jan

Re: gdb-7.5 branch ready for first release?

[Joel Brobecker]

> As various fixes (and not just regression) get checked in plan to check in
> also
> 	Re: [PATCH] refreshed patch for PR 11804 and PR 9904
> 	http://sourceware.org/ml/gdb-patches/2012-07/msg00797.html
> (fix of gcore of RELRO executables)
> It is a FAQ at least least on #gdb, fixed longterm in Fedora.

As long as the patch is deemed very safe (and long-term exposure
through Fedora helps in that respect), I agree it is fine to put it
in the branch as well.

-- 
Joel

Re: gdb-7.5 branch ready for first release?

[Luis Gustavo]

On 08/05/2012 10:41 PM, Joel Brobecker wrote:
> I thought I had replied to this message, but it looks like I didn't.
> Ooops!
>
>> I would like to put in a few bug fixes that are pending comment:
>>
>>      http://sourceware.org/ml/gdb-patches/2012-07/msg00800.html
>>      http://sourceware.org/ml/gdb-patches/2012-08/msg00029.html
>>      http://sourceware.org/ml/gdb-patches/2012-08/msg00074.html
>>      http://sourceware.org/ml/gdb-patches/2012-08/msg00117.html
>
> That would be fine, I think. I don't see us in a rush to release,
> so we can wait an extra week. Let me know when they are in!
>

Not wanting to stall the release, there's a problem with hw watchpoints 
for ppc that i would like to address.

The fix is relatively small and localized and is described here:
http://sourceware.org/ml/gdb-patches/2012-08/msg00173.html

Let me know if that's not acceptable.

Luis

Re: gdb-7.5 branch ready for first release?

[Joel Brobecker]

Hi Tom,

Just going over the patches you pointed out:

> I would like to put in a few bug fixes that are pending comment:
> 
>     http://sourceware.org/ml/gdb-patches/2012-07/msg00800.html
>     http://sourceware.org/ml/gdb-patches/2012-08/msg00029.html
>     http://sourceware.org/ml/gdb-patches/2012-08/msg00074.html

Looks like all 3 have been checked in, now.

>     http://sourceware.org/ml/gdb-patches/2012-08/msg00117.html

Looks a little tricky, and MarkK expressed some reservations on
the approach. I suggest we keep this one out of 7.5?

If there is an agreement, and no one else has anything blocking,
I could make the release tomorrow, giving people the weekend to
start playing with it.

-- 
Joel

Re: gdb-7.5 branch ready for first release?

[Tom Tromey]

Tom> http://sourceware.org/ml/gdb-patches/2012-08/msg00117.html

Joel> Looks a little tricky, and MarkK expressed some reservations on
Joel> the approach. I suggest we keep this one out of 7.5?

FWIW I already put it on the branch.

I tend to think it belongs there.  If I understand Mark's objections
correctly -- he still hasn't written back with the details we asked for
-- they are about the design of the tailcall sniffer.

However, this patch doesn't affect that design one way or another.
Instead it fixes a concrete bug in the code.  It does so in a way that,
I believe, is safe and relatively clear.

Tom

Re: gdb-7.5 branch ready for first release?

[Joel Brobecker]

> Joel> Looks a little tricky, and MarkK expressed some reservations on
> Joel> the approach. I suggest we keep this one out of 7.5?
> 
> FWIW I already put it on the branch.

Ha! That makes it simpler :).

> However, this patch doesn't affect that design one way or another.
> Instead it fixes a concrete bug in the code.  It does so in a way that,
> I believe, is safe and relatively clear.

Works for me. I'll try making the release tomorrow.

Thanks, Tom.
-- 
Joel

Re: gdb-7.5 branch ready for first release?

[Ralf Corsepius]

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

On 08/03/2012 03:45 PM, Joel Brobecker wrote:
> Hello,
>
> It looks like we no longer have any blocking issue with the 7.5 branch,
> so perhaps we are ready to create the first release off that branch?
>
> Please let me know if I should wait. Otherwise, I will try to create
> the release early next week.
>

I am facing various (IMO pretty serious) "cast from pointer to integer 
of different size" warnings when building gdb-7.4.91 Canadian cross for 
several targets (w/ simulators enabled) for mingw32-w64 hosts on Linux 
build-hosts.

My personal attempt to work around these issues (so far) is the patch 
below, which involves using inttypes.h and stdint.h (This is not meant 
to be a proper patch submission - This is WIP).

Would such a patch be acceptable or is using inttypes.h/stdint.h being 
considered a "no-go"?

Ralf





[-- Attachment #2: gdb.diff --]
[-- Type: text/x-patch, Size: 8353 bytes --]

diff --git a/gdb/symfile.c b/gdb/symfile.c
index 01252e2..01720fa 100644
--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -2889,8 +2889,8 @@ allocate_symtab (const char *filename, struct objfile *objfile)
 			      last_objfile_name);
 	}
       fprintf_unfiltered (gdb_stdlog,
-			  "Created symtab 0x%lx for module %s.\n",
-			  (long) symtab, filename);
+			  "Created symtab 0x%p for module %s.\n",
+			  symtab, filename);
     }
 
   return (symtab);
diff --git a/sim/common/sim-events.c b/sim/common/sim-events.c
index 4e06a2c..da91e14 100644
--- a/sim/common/sim-events.c
+++ b/sim/common/sim-events.c
@@ -38,6 +38,8 @@
 #include <stdlib.h>
 #endif
 
+#include <inttypes.h>
+
 #include <signal.h> /* For SIGPROCMASK et al. */
 
 typedef enum {
@@ -418,14 +420,14 @@ update_time_from_event (SIM_DESC sd)
 	   event = event->next, i++)
 	{
 	  ETRACE ((_ETRACE,
-		   "event time-from-event - time %ld, delta %ld - event %d, tag 0x%lx, time %ld, handler 0x%lx, data 0x%lx%s%s\n",
-		   (long)current_time,
-		   (long)events->time_from_event,
+		   "event time-from-event - time %" PRId64 ", delta %" PRId64 " - event %d, tag 0x%p, time %" PRId64 ", handler 0x%p, data 0x%p%s%s\n",
+		   current_time,
+		   events->time_from_event,
 		   i,
-		   (long)event,
-		   (long)event->time_of_event,
-		   (long)event->handler,
-		   (long)event->data,
+		   event,
+		   event->time_of_event,
+		   event->handler,
+		   event->data,
 		   (event->trace != NULL) ? ", " : "",
 		   (event->trace != NULL) ? event->trace : ""));
 	}
@@ -525,12 +527,12 @@ sim_events_schedule_vtracef (SIM_DESC sd,
     new_event->trace = NULL;
   insert_sim_event (sd, new_event, delta_time);
   ETRACE ((_ETRACE,
-	   "event scheduled at %ld - tag 0x%lx - time %ld, handler 0x%lx, data 0x%lx%s%s\n",
+	   "event scheduled at %ld - tag 0x%p - time %ld, handler 0x%p, data 0x%p%s%s\n",
 	   (long)sim_events_time (sd),
-	   (long)new_event,
+	   new_event,
 	   (long)new_event->time_of_event,
-	   (long)new_event->handler,
-	   (long)new_event->data,
+	   new_event->handler,
+	   new_event->data,
 	   (new_event->trace != NULL) ? ", " : "",
 	   (new_event->trace != NULL) ? new_event->trace : ""));
   return new_event;
@@ -577,12 +579,12 @@ sim_events_schedule_after_signal (SIM_DESC sd,
 #endif
 
   ETRACE ((_ETRACE,
-	   "signal scheduled at %ld - tag 0x%lx - time %ld, handler 0x%lx, data 0x%lx\n",
-	   (long)sim_events_time (sd),
-	   (long)new_event,
-	   (long)new_event->time_of_event,
-	   (long)new_event->handler,
-	   (long)new_event->data));
+	   "signal scheduled at %" PRId64 " - tag 0x%p - time %" PRId64 ", handler 0x%p, data 0x%p\n",
+	   sim_events_time (sd),
+	   new_event,
+	   new_event->time_of_event,
+	   new_event->handler,
+	   new_event->data));
 }
 #endif
 
@@ -613,12 +615,12 @@ sim_events_watch_clock (SIM_DESC sd,
   events->watchpoints = new_event;
   events->work_pending = 1;
   ETRACE ((_ETRACE,
-	  "event watching clock at %ld - tag 0x%lx - wallclock %ld, handler 0x%lx, data 0x%lx\n",
-	   (long)sim_events_time (sd),
-	   (long)new_event,
-	   (long)new_event->wallclock,
-	   (long)new_event->handler,
-	   (long)new_event->data));
+	  "event watching clock at %" PRId64 " - tag 0x%p - wallclock %d, handler 0x%p, data 0x%p\n",
+	   sim_events_time (sd),
+	   new_event,
+	   new_event->wallclock,
+	   new_event->handler,
+	   new_event->data));
   return new_event;
 }
 #endif
@@ -689,14 +691,14 @@ sim_events_watch_sim (SIM_DESC sd,
   events->watchpoints = new_event;
   events->work_pending = 1;
   ETRACE ((_ETRACE,
-	   "event watching host at %ld - tag 0x%lx - host-addr 0x%lx, 0x%lx..0x%lx, handler 0x%lx, data 0x%lx\n",
-	   (long)sim_events_time (sd),
-	   (long)new_event,
-	   (long)new_event->host_addr,
-	   (long)new_event->lb,
-	   (long)new_event->ub,
-	   (long)new_event->handler,
-	   (long)new_event->data));
+	   "event watching host at %" PRId64 " - tag 0x%p - host-addr 0x%p, 0x%x..0x%x, handler 0x%p, data 0x%p\n",
+	   sim_events_time (sd),
+	   new_event,
+	   new_event->host_addr,
+	   new_event->lb,
+	   new_event->ub,
+	   new_event->handler,
+	   new_event->data));
   return new_event;
 }
 #endif
@@ -769,14 +771,14 @@ sim_events_watch_core (SIM_DESC sd,
   events->watchpoints = new_event;
   events->work_pending = 1;
   ETRACE ((_ETRACE,
-	   "event watching host at %ld - tag 0x%lx - host-addr 0x%lx, 0x%lx..0x%lx, handler 0x%lx, data 0x%lx\n",
-	   (long)sim_events_time (sd),
-	   (long)new_event,
-	   (long)new_event->host_addr,
-	   (long)new_event->lb,
-	   (long)new_event->ub,
-	   (long)new_event->handler,
-	   (long)new_event->data));
+	   "event watching host at %" PRId64 " - tag 0x%p - host-addr 0x%p, 0x%x..0x%x, handler 0x%p, data 0x%p\n",
+	   sim_events_time (sd),
+	   new_event,
+	   new_event->host_addr,
+	   new_event->lb,
+	   new_event->ub,
+	   new_event->handler,
+	   new_event->data));
   return new_event;
 }
 #endif
@@ -803,12 +805,12 @@ sim_events_deschedule (SIM_DESC sd,
 	      sim_event *dead = *ptr_to_current;
 	      *ptr_to_current = dead->next;
 	      ETRACE ((_ETRACE,
-		       "event/watch descheduled at %ld - tag 0x%lx - time %ld, handler 0x%lx, data 0x%lx%s%s\n",
-		       (long) sim_events_time (sd),
-		       (long) event_to_remove,
-		       (long) dead->time_of_event,
-		       (long) dead->handler,
-		       (long) dead->data,
+		       "event/watch descheduled at %" PRId64 " - tag 0x%p - time %" PRId64 ", handler 0x%p, data 0x%p%s%s\n",
+		       sim_events_time (sd),
+		       event_to_remove,
+		       dead->time_of_event,
+		       dead->handler,
+		       dead->data,
 		       (dead->trace != NULL) ? ", " : "",
 		       (dead->trace != NULL) ? dead->trace : ""));
 	      sim_events_free (sd, dead);
@@ -819,9 +821,9 @@ sim_events_deschedule (SIM_DESC sd,
 	}
     }
   ETRACE ((_ETRACE,
-	   "event/watch descheduled at %ld - tag 0x%lx - not found\n",
-	   (long) sim_events_time (sd),
-	   (long) event_to_remove));
+	   "event/watch descheduled at %" PRId64 " - tag 0x%p - not found\n",
+	   sim_events_time (sd),
+	   event_to_remove));
 }
 #endif
 
@@ -1146,11 +1148,11 @@ sim_events_process (SIM_DESC sd)
 	  sim_event_handler *handler = to_do->handler;
 	  void *data = to_do->data;
 	  ETRACE ((_ETRACE,
-		   "event issued at %ld - tag 0x%lx - handler 0x%lx, data 0x%lx%s%s\n",
-		   (long) event_time,
-		   (long) to_do,
-		   (long) handler,
-		   (long) data,
+		   "event issued at %" PRId64 " - tag 0x%p - handler 0x%p, data 0x%p%s%s\n",
+		   event_time,
+		   to_do,
+		   handler,
+		   data,
 		   (to_do->trace != NULL) ? ", " : "",
 		   (to_do->trace != NULL) ? to_do->trace : ""));
 	  sim_events_free (sd, to_do);
@@ -1174,11 +1176,11 @@ sim_events_process (SIM_DESC sd)
       events->queue = to_do->next;
       update_time_from_event (sd);
       ETRACE ((_ETRACE,
-	       "event issued at %ld - tag 0x%lx - handler 0x%lx, data 0x%lx%s%s\n",
-	       (long) event_time,
-	       (long) to_do,
-	       (long) handler,
-	       (long) data,
+	       "event issued at %" PRId64 " - tag 0x%p - handler 0x%p, data 0x%p%s%s\n",
+	       event_time,
+	       to_do,
+	       handler,
+	       data,
 	       (to_do->trace != NULL) ? ", " : "",
 	       (to_do->trace != NULL) ? to_do->trace : ""));
       sim_events_free (sd, to_do);
diff --git a/sim/ppc/hw_glue.c b/sim/ppc/hw_glue.c
index d7ad929..aff7dd6 100644
--- a/sim/ppc/hw_glue.c
+++ b/sim/ppc/hw_glue.c
@@ -194,13 +194,13 @@ hw_glue_init_address(device *me)
     if (glue->sizeof_output == 0)
       device_error(me, "at least one reg property size must be nonzero");
     if (glue->sizeof_output % sizeof(unsigned_word) != 0)
-      device_error(me, "reg property size must be %d aligned", sizeof(unsigned_word));
+      device_error(me, "reg property size must be %zd aligned", sizeof(unsigned_word));
     /* and the address */
     device_address_to_attach_address(device_parent(me),
 				     &unit.address, &glue->space, &glue->address,
 				     me);
     if (glue->address % (sizeof(unsigned_word) * max_nr_interrupts) != 0)
-      device_error(me, "reg property address must be %d aligned",
+      device_error(me, "reg property address must be %zd aligned",
 		   sizeof(unsigned_word) * max_nr_interrupts);
     glue->nr_outputs = glue->sizeof_output / sizeof(unsigned_word);
     glue->output = zalloc(glue->sizeof_output);

Re: gdb-7.5 branch ready for first release?

[Tom Tromey]

>>>>> "Ralf" == Ralf Corsepius <ralf.corsepius@googlemail.com> writes:

Ralf> Would such a patch be acceptable or is using inttypes.h/stdint.h being
Ralf> considered a "no-go"?

I can't speak to the sim changes.

For this one:

Ralf> diff --git a/gdb/symfile.c b/gdb/symfile.c
Ralf> index 01252e2..01720fa 100644
Ralf> --- a/gdb/symfile.c
Ralf> +++ b/gdb/symfile.c
Ralf> @@ -2889,8 +2889,8 @@ allocate_symtab (const char *filename, struct objfile *objfile)
Ralf>  			      last_objfile_name);
Ralf>  	}
Ralf>        fprintf_unfiltered (gdb_stdlog,
Ralf> -			  "Created symtab 0x%lx for module %s.\n",
Ralf> -			  (long) symtab, filename);
Ralf> +			  "Created symtab 0x%p for module %s.\n",
Ralf> +			  symtab, filename);
Ralf>      }

Rather than %p I think it is the norm in gdb to use %s with
host_address_to_string.

Tom

Re: gdb-7.5 branch ready for first release?

[Ralf Corsepius]

On 08/08/2012 10:46 PM, Tom Tromey wrote:
>>>>>> "Ralf" == Ralf Corsepius <ralf.corsepius@googlemail.com> writes:
>
> Ralf> Would such a patch be acceptable or is using inttypes.h/stdint.h being
> Ralf> considered a "no-go"?
>
> I can't speak to the sim changes.
>
> For this one:
>
> Ralf> diff --git a/gdb/symfile.c b/gdb/symfile.c
> Ralf> index 01252e2..01720fa 100644
> Ralf> --- a/gdb/symfile.c
> Ralf> +++ b/gdb/symfile.c
> Ralf> @@ -2889,8 +2889,8 @@ allocate_symtab (const char *filename, struct objfile *objfile)
> Ralf>  			      last_objfile_name);
> Ralf>  	}
> Ralf>        fprintf_unfiltered (gdb_stdlog,
> Ralf> -			  "Created symtab 0x%lx for module %s.\n",
> Ralf> -			  (long) symtab, filename);
> Ralf> +			  "Created symtab 0x%p for module %s.\n",
> Ralf> +			  symtab, filename);
> Ralf>      }
>
> Rather than %p I think it is the norm in gdb to use %s with
> host_address_to_string.

OK, thanks for the pointer. I'll try to take this into account when 
revisiting this issue next time [1].

Ralf

[1] Due to vaction, this is unlikely to happen before Aug 20 ;)