New ARI warning Wed May 23 01:55:03 UTC 2012

Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed

* New ARI warning Wed May 23 01:55:03 UTC 2012
@ 2012-05-23  1:55 GDB Administrator
  2012-05-23  4:18 ` Sergio Durigan Junior
  0 siblings, 1 reply; 23+ messages in thread
From: GDB Administrator @ 2012-05-23  1:55 UTC (permalink / raw)
  To: gdb-patches

118d117
< gdb/common/buffer.c:51: regression: abort: Do not use abort, instead use internal_error; GDB should never abort
gdb/common/buffer.c:51:    abort ();
263a263,264
> gdb/dwarf2-frame.c:419: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2-frame.c:419:      unsigned long long utmp, reg;
> gdb/dwarf2-frame.c:420: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2-frame.c:420:      long long offset;
264a266,283
> gdb/dwarf2-frame.c:1631: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2-frame.c:1631:	unsigned long long value;
> gdb/dwarf2-frame.c:1648: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2-frame.c:1648:	long long value;
> gdb/dwarf2-frame.c:1833: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2-frame.c:1833:  long long sleb128;
> gdb/dwarf2-frame.c:1834: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2-frame.c:1834:  unsigned long long uleb128;
> gdb/dwarf2-frame.c:1981: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2-frame.c:1981:	  unsigned long long length;
> gdb/dwarf2-frame.c:2098: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2-frame.c:2098:	  unsigned long long length;
> gdb/dwarf2expr.c:376: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:376:		   unsigned long long *r)
> gdb/dwarf2expr.c:388: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:388:		   long long *r)
> gdb/dwarf2expr.c:468: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:468:  unsigned long long dwarf_reg;
> gdb/dwarf2expr.c:512: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:512:  unsigned long long dwarf_reg;
> gdb/dwarf2expr.c:513: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:513:  long long offset;
> gdb/dwarf2expr.c:571: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:571:  long long fb_offset;
> gdb/dwarf2expr.c:598: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:598:  unsigned long long dwarf_reg;
> gdb/dwarf2expr.c:599: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:599:  long long sp_offset;
> gdb/dwarf2expr.c:668: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:668:      unsigned long long uoffset, reg;
> gdb/dwarf2expr.c:669: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:669:      long long offset;
> gdb/dwarf2expr.c:842: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:842:	    unsigned long long len;
> gdb/dwarf2expr.c:863: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:863:	    long long len;
265a285,287
> gdb/dwarf2expr.c:1294: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:1294:            unsigned long long size;
> gdb/dwarf2expr.c:1311: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:1311:	    unsigned long long size, offset;
> gdb/dwarf2expr.c:1357: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.c:1357:	    unsigned long long len;
266a289,310
> gdb/dwarf2expr.h:312: code: inline: Do not use the inline attribute; since the compiler generally ignores this, better algorithm selection is needed to improved performance
gdb/dwarf2expr.h:312:static inline const gdb_byte *
> gdb/dwarf2expr.h:314: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.h:314:		  unsigned long long *r)
> gdb/dwarf2expr.h:323: code: inline: Do not use the inline attribute; since the compiler generally ignores this, better algorithm selection is needed to improved performance
gdb/dwarf2expr.h:323:static inline const gdb_byte *
> gdb/dwarf2expr.h:325: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.h:325:		  long long *r)
> gdb/dwarf2expr.h:334: code: inline: Do not use the inline attribute; since the compiler generally ignores this, better algorithm selection is needed to improved performance
gdb/dwarf2expr.h:334:static inline const gdb_byte *
> gdb/dwarf2expr.h:346: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.h:346:					  unsigned long long *r);
> gdb/dwarf2expr.h:350: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2expr.h:350:					  long long *r);
> gdb/dwarf2loc.c:142: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:142:  unsigned long long low_index, high_index;
> gdb/dwarf2loc.c:2569: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:2569:      unsigned long long uoffset, reg;
> gdb/dwarf2loc.c:2570: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:2570:      long long offset;
> gdb/dwarf2loc.c:2728: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:2728:	    unsigned long long len;
> gdb/dwarf2loc.c:3078: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:3078:	    unsigned long long size, offset;
> gdb/dwarf2loc.c:3270: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:3270:      unsigned long long reg;
> gdb/dwarf2loc.c:3281: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:3281:      long long frame_offset;
> gdb/dwarf2loc.c:3284: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:3284:      long long base_offset = 0;
> gdb/dwarf2loc.c:3338: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:3338:      long long offset;
> gdb/dwarf2loc.c:3412: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:3412:      unsigned long long ul;
> gdb/dwarf2loc.c:3413: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:3413:      long long l;
> gdb/dwarf2loc.c:3633: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:3633:	    unsigned long long offset;
> gdb/dwarf2loc.c:3688: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:3688:	    unsigned long long reg;
> gdb/dwarf2loc.c:3797: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:3797:	      unsigned long long bytes;
> gdb/dwarf2loc.c:3810: code: long long: Do not use 'long long', instead use LONGEST
gdb/dwarf2loc.c:3810:	      unsigned long long bits, offset;
973,974d1016
< gdb/tracepoint.c:1808: gettext: _ markup: All messages should be marked up with _.
gdb/tracepoint.c:1808:    warning ("Target does not support trace user/notes, info ignored");
< gdb/tracepoint.c:1894: gettext: _ markup: All messages should be marked up with _.
gdb/tracepoint.c:1894:    warning ("Target does not support trace notes, note ignored");
979,981d1020
< gdb/tracepoint.c:3204: gettext: _ markup: All messages should be marked up with _.
gdb/tracepoint.c:3204:    warning ("Target does not support trace notes, user ignored");
< gdb/tracepoint.c:3216: gettext: _ markup: All messages should be marked up with _.
gdb/tracepoint.c:3216:    warning ("Target does not support trace notes, note ignored");
< gdb/tracepoint.c:3228: gettext: _ markup: All messages should be marked up with _.
gdb/tracepoint.c:3228:    warning ("Target does not support trace notes, stop note ignored");


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-23  1:55 New ARI warning Wed May 23 01:55:03 UTC 2012 GDB Administrator
@ 2012-05-23  4:18 ` Sergio Durigan Junior
  2012-05-23  7:10   ` Doug Evans
  2012-05-23  7:10   ` Andreas Schwab
  0 siblings, 2 replies; 23+ messages in thread
From: Sergio Durigan Junior @ 2012-05-23  4:18 UTC (permalink / raw)
  To: gdb-patches

WDYT about the following patch?  I would like you to take a look at the
gdb/dwarf2expr.h's castings that I had to make in order to get the
compilation right.

Thanks,

-- 
Sergio

diff --git a/gdb/dwarf2-frame.c b/gdb/dwarf2-frame.c
index 96fa451..fd463ed 100644
--- a/gdb/dwarf2-frame.c
+++ b/gdb/dwarf2-frame.c
@@ -416,8 +416,8 @@ execute_cfa_program (struct dwarf2_fde *fde, const gdb_byte *insn_ptr,
   while (insn_ptr < insn_end && fs->pc <= pc)
     {
       gdb_byte insn = *insn_ptr++;
-      unsigned long long utmp, reg;
-      long long offset;
+      ULONGEST utmp, reg;
+      LONGEST offset;
 
       if ((insn & 0xc0) == DW_CFA_advance_loc)
 	fs->pc += (insn & 0x3f) * fs->code_align;
@@ -1628,7 +1628,7 @@ read_encoded_value (struct comp_unit *unit, gdb_byte encoding,
     {
     case DW_EH_PE_uleb128:
       {
-	unsigned long long value;
+	ULONGEST value;
 	const gdb_byte *end_buf = buf + (sizeof (value) + 1) * 8 / 7;
 
 	*bytes_read_ptr += safe_read_uleb128 (buf, end_buf, &value) - buf;
@@ -1645,7 +1645,7 @@ read_encoded_value (struct comp_unit *unit, gdb_byte encoding,
       return (base + bfd_get_64 (unit->abfd, (bfd_byte *) buf));
     case DW_EH_PE_sleb128:
       {
-	long long value;
+	LONGEST value;
 	const gdb_byte *end_buf = buf + (sizeof (value) + 1) * 8 / 7;
 
 	*bytes_read_ptr += safe_read_sleb128 (buf, end_buf, &value) - buf;
@@ -1830,8 +1830,8 @@ decode_frame_entry_1 (struct comp_unit *unit, const gdb_byte *start,
   int dwarf64_p;
   ULONGEST cie_id;
   ULONGEST cie_pointer;
-  long long sleb128;
-  unsigned long long uleb128;
+  LONGEST sleb128;
+  ULONGEST uleb128;
 
   buf = start;
   length = read_initial_length (unit->abfd, buf, &bytes_read);
@@ -1978,7 +1978,7 @@ decode_frame_entry_1 (struct comp_unit *unit, const gdb_byte *start,
       cie->saw_z_augmentation = (*augmentation == 'z');
       if (cie->saw_z_augmentation)
 	{
-	  unsigned long long length;
+	  ULONGEST length;
 
 	  buf = gdb_read_uleb128 (buf, end, &length);
 	  if (buf == NULL)
@@ -2095,7 +2095,7 @@ decode_frame_entry_1 (struct comp_unit *unit, const gdb_byte *start,
 	 can skip the whole thing.  */
       if (fde->cie->saw_z_augmentation)
 	{
-	  unsigned long long length;
+	  ULONGEST length;
 
 	  buf = gdb_read_uleb128 (buf, end, &length);
 	  if (buf == NULL)
diff --git a/gdb/dwarf2expr.c b/gdb/dwarf2expr.c
index 80c6e17..fc29637 100644
--- a/gdb/dwarf2expr.c
+++ b/gdb/dwarf2expr.c
@@ -373,7 +373,7 @@ dwarf_expr_eval (struct dwarf_expr_context *ctx, const gdb_byte *addr,
 
 const gdb_byte *
 safe_read_uleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
-		   unsigned long long *r)
+		   ULONGEST *r)
 {
   buf = gdb_read_uleb128 (buf, buf_end, r);
   if (buf == NULL)
@@ -385,7 +385,7 @@ safe_read_uleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
 
 const gdb_byte *
 safe_read_sleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
-		   long long *r)
+		   LONGEST *r)
 {
   buf = gdb_read_sleb128 (buf, buf_end, r);
   if (buf == NULL)
@@ -465,7 +465,7 @@ dwarf_get_base_type (struct dwarf_expr_context *ctx, cu_offset die, int size)
 int
 dwarf_block_to_dwarf_reg (const gdb_byte *buf, const gdb_byte *buf_end)
 {
-  unsigned long long dwarf_reg;
+  ULONGEST dwarf_reg;
 
   if (buf_end <= buf)
     return -1;
@@ -509,8 +509,8 @@ int
 dwarf_block_to_dwarf_reg_deref (const gdb_byte *buf, const gdb_byte *buf_end,
 				CORE_ADDR *deref_size_return)
 {
-  unsigned long long dwarf_reg;
-  long long offset;
+  ULONGEST dwarf_reg;
+  LONGEST offset;
 
   if (buf_end <= buf)
     return -1;
@@ -568,7 +568,7 @@ int
 dwarf_block_to_fb_offset (const gdb_byte *buf, const gdb_byte *buf_end,
 			  CORE_ADDR *fb_offset_return)
 {
-  long long fb_offset;
+  LONGEST fb_offset;
 
   if (buf_end <= buf)
     return 0;
@@ -595,8 +595,8 @@ int
 dwarf_block_to_sp_offset (struct gdbarch *gdbarch, const gdb_byte *buf,
 			  const gdb_byte *buf_end, CORE_ADDR *sp_offset_return)
 {
-  unsigned long long dwarf_reg;
-  long long sp_offset;
+  ULONGEST dwarf_reg;
+  LONGEST sp_offset;
 
   if (buf_end <= buf)
     return 0;
@@ -665,8 +665,8 @@ execute_stack_op (struct dwarf_expr_context *ctx,
 	 This is just an optimization, so it's always ok to punt
 	 and leave this as 0.  */
       int in_stack_memory = 0;
-      unsigned long long uoffset, reg;
-      long long offset;
+      ULONGEST uoffset, reg;
+      LONGEST offset;
       struct value *result_val = NULL;
 
       /* The DWARF expression might have a bug causing an infinite
@@ -839,7 +839,7 @@ execute_stack_op (struct dwarf_expr_context *ctx,
 
 	case DW_OP_implicit_value:
 	  {
-	    unsigned long long len;
+	    ULONGEST len;
 
 	    op_ptr = safe_read_uleb128 (op_ptr, op_end, &len);
 	    if (op_ptr + len > op_end)
@@ -860,7 +860,7 @@ execute_stack_op (struct dwarf_expr_context *ctx,
 
 	case DW_OP_GNU_implicit_pointer:
 	  {
-	    long long len;
+	    LONGEST len;
 
 	    if (ctx->ref_addr_size == -1)
 	      error (_("DWARF-2 expression error: DW_OP_GNU_implicit_pointer "
@@ -1291,7 +1291,7 @@ execute_stack_op (struct dwarf_expr_context *ctx,
 
         case DW_OP_piece:
           {
-            unsigned long long size;
+            ULONGEST size;
 
             /* Record the piece.  */
             op_ptr = safe_read_uleb128 (op_ptr, op_end, &size);
@@ -1308,7 +1308,7 @@ execute_stack_op (struct dwarf_expr_context *ctx,
 
 	case DW_OP_bit_piece:
 	  {
-	    unsigned long long size, offset;
+	    ULONGEST size, offset;
 
             /* Record the piece.  */
 	    op_ptr = safe_read_uleb128 (op_ptr, op_end, &size);
@@ -1354,7 +1354,7 @@ execute_stack_op (struct dwarf_expr_context *ctx,
 	
 	case DW_OP_GNU_entry_value:
 	  {
-	    unsigned long long len;
+	    ULONGEST len;
 	    int dwarf_reg;
 	    CORE_ADDR deref_size;
 
diff --git a/gdb/dwarf2expr.h b/gdb/dwarf2expr.h
index 82a5a93..57fe39e 100644
--- a/gdb/dwarf2expr.h
+++ b/gdb/dwarf2expr.h
@@ -311,9 +311,9 @@ int dwarf_block_to_sp_offset (struct gdbarch *gdbarch, const gdb_byte *buf,
 
 static inline const gdb_byte *
 gdb_read_uleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
-		  unsigned long long *r)
+		  ULONGEST *r)
 {
-  size_t bytes_read = read_uleb128_to_ull (buf, buf_end, r);
+  size_t bytes_read = read_uleb128_to_ull (buf, buf_end, (unsigned long long *) r);
 
   if (bytes_read == 0)
     return NULL;
@@ -322,9 +322,9 @@ gdb_read_uleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
 
 static inline const gdb_byte *
 gdb_read_sleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
-		  long long *r)
+		  LONGEST *r)
 {
-  size_t bytes_read = read_sleb128_to_ll (buf, buf_end, r);
+  size_t bytes_read = read_sleb128_to_ll (buf, buf_end, (long long *) r);
 
   if (bytes_read == 0)
     return NULL;
@@ -343,11 +343,11 @@ gdb_skip_leb128 (const gdb_byte *buf, const gdb_byte *buf_end)
 
 extern const gdb_byte *safe_read_uleb128 (const gdb_byte *buf,
 					  const gdb_byte *buf_end,
-					  unsigned long long *r);
+					  ULONGEST *r);
 
 extern const gdb_byte *safe_read_sleb128 (const gdb_byte *buf,
 					  const gdb_byte *buf_end,
-					  long long *r);
+					  LONGEST *r);
 
 extern const gdb_byte *safe_skip_leb128 (const gdb_byte *buf,
 					 const gdb_byte *buf_end);
diff --git a/gdb/dwarf2loc.c b/gdb/dwarf2loc.c
index 9bd7741..14af020 100644
--- a/gdb/dwarf2loc.c
+++ b/gdb/dwarf2loc.c
@@ -139,7 +139,7 @@ decode_debug_loc_dwo_addresses (struct dwarf2_per_cu_data *per_cu,
 				const gdb_byte **new_ptr,
 				CORE_ADDR *low, CORE_ADDR *high)
 {
-  unsigned long long low_index, high_index;
+  ULONGEST low_index, high_index;
 
   if (loc_ptr == buf_end)
     return DEBUG_LOC_BUFFER_OVERFLOW;
@@ -2566,8 +2566,8 @@ dwarf2_compile_expr_to_ax (struct agent_expr *expr, struct axs_value *loc,
   while (op_ptr < op_end)
     {
       enum dwarf_location_atom op = *op_ptr;
-      unsigned long long uoffset, reg;
-      long long offset;
+      ULONGEST uoffset, reg;
+      LONGEST offset;
       int i;
 
       offsets[op_ptr - base] = expr->len;
@@ -2725,7 +2725,7 @@ dwarf2_compile_expr_to_ax (struct agent_expr *expr, struct axs_value *loc,
 
 	case DW_OP_implicit_value:
 	  {
-	    unsigned long long len;
+	    ULONGEST len;
 
 	    op_ptr = safe_read_uleb128 (op_ptr, op_end, &len);
 	    if (op_ptr + len > op_end)
@@ -3075,7 +3075,7 @@ dwarf2_compile_expr_to_ax (struct agent_expr *expr, struct axs_value *loc,
         case DW_OP_piece:
 	case DW_OP_bit_piece:
 	  {
-	    unsigned long long size, offset;
+	    ULONGEST size, offset;
 
 	    if (op_ptr - 1 == previous_piece)
 	      error (_("Cannot translate empty pieces to agent expressions"));
@@ -3267,7 +3267,7 @@ locexpr_describe_location_piece (struct symbol *symbol, struct ui_file *stream,
     }
   else if (data[0] == DW_OP_regx)
     {
-      unsigned long long reg;
+      ULONGEST reg;
 
       data = safe_read_uleb128 (data + 1, end, &reg);
       fprintf_filtered (stream, _("a variable in $%s"),
@@ -3278,10 +3278,10 @@ locexpr_describe_location_piece (struct symbol *symbol, struct ui_file *stream,
       struct block *b;
       struct symbol *framefunc;
       int frame_reg = 0;
-      long long frame_offset;
+      LONGEST frame_offset;
       const gdb_byte *base_data, *new_data, *save_data = data;
       size_t base_size;
-      long long base_offset = 0;
+      LONGEST base_offset = 0;
 
       new_data = safe_read_sleb128 (data + 1, end, &frame_offset);
       if (!piece_end_p (new_data, end))
@@ -3335,7 +3335,7 @@ locexpr_describe_location_piece (struct symbol *symbol, struct ui_file *stream,
   else if (data[0] >= DW_OP_breg0 && data[0] <= DW_OP_breg31
 	   && piece_end_p (data, end))
     {
-      long long offset;
+      LONGEST offset;
 
       data = safe_read_sleb128 (data + 1, end, &offset);
 
@@ -3409,8 +3409,8 @@ disassemble_dwarf_expression (struct ui_file *stream,
 	     || (data[0] != DW_OP_piece && data[0] != DW_OP_bit_piece)))
     {
       enum dwarf_location_atom op = *data++;
-      unsigned long long ul;
-      long long l;
+      ULONGEST ul;
+      LONGEST l;
       const char *name;
 
       name = get_DW_OP_name (op);
@@ -3630,7 +3630,7 @@ disassemble_dwarf_expression (struct ui_file *stream,
 
 	case DW_OP_bit_piece:
 	  {
-	    unsigned long long offset;
+	    ULONGEST offset;
 
 	    data = safe_read_uleb128 (data, end, &ul);
 	    data = safe_read_uleb128 (data, end, &offset);
@@ -3685,7 +3685,7 @@ disassemble_dwarf_expression (struct ui_file *stream,
 
 	case DW_OP_GNU_regval_type:
 	  {
-	    unsigned long long reg;
+	    ULONGEST reg;
 	    cu_offset type_die;
 	    struct type *type;
 
@@ -3794,7 +3794,7 @@ locexpr_describe_location_1 (struct symbol *symbol, CORE_ADDR addr,
 	    fprintf_filtered (stream, "   ");
 	  if (data[0] == DW_OP_piece)
 	    {
-	      unsigned long long bytes;
+	      ULONGEST bytes;
 
 	      data = safe_read_uleb128 (data + 1, end, &bytes);
 
@@ -3807,7 +3807,7 @@ locexpr_describe_location_1 (struct symbol *symbol, CORE_ADDR addr,
 	    }
 	  else if (data[0] == DW_OP_bit_piece)
 	    {
-	      unsigned long long bits, offset;
+	      ULONGEST bits, offset;
 
 	      data = safe_read_uleb128 (data + 1, end, &bits);
 	      data = safe_read_uleb128 (data, end, &offset);


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-23  4:18 ` Sergio Durigan Junior
@ 2012-05-23  7:10   ` Doug Evans
  2012-05-23  7:27     ` Doug Evans
  2012-05-23  7:10   ` Andreas Schwab
  1 sibling, 1 reply; 23+ messages in thread
From: Doug Evans @ 2012-05-23  7:10 UTC (permalink / raw)
  To: Sergio Durigan Junior; +Cc: gdb-patches

Well, blech.
src/include/leb128.h uses long long per request, so that's what I used here.
src/include/anything obviously cannot use LONGEST/ULONGEST.

Are long long's really verboten?

I suppose I could create a gdb-leb128.h that used LONGEST/ULONGEST,
but blech.


On Tue, May 22, 2012 at 9:17 PM, Sergio Durigan Junior
<sergiodj@redhat.com> wrote:
> WDYT about the following patch?  I would like you to take a look at the
> gdb/dwarf2expr.h's castings that I had to make in order to get the
> compilation right.
>
> Thanks,
>
> --
> Sergio
>
> diff --git a/gdb/dwarf2-frame.c b/gdb/dwarf2-frame.c
> index 96fa451..fd463ed 100644
> --- a/gdb/dwarf2-frame.c
> +++ b/gdb/dwarf2-frame.c
> @@ -416,8 +416,8 @@ execute_cfa_program (struct dwarf2_fde *fde, const gdb_byte *insn_ptr,
>   while (insn_ptr < insn_end && fs->pc <= pc)
>     {
>       gdb_byte insn = *insn_ptr++;
> -      unsigned long long utmp, reg;
> -      long long offset;
> +      ULONGEST utmp, reg;
> +      LONGEST offset;
>
>       if ((insn & 0xc0) == DW_CFA_advance_loc)
>        fs->pc += (insn & 0x3f) * fs->code_align;
> @@ -1628,7 +1628,7 @@ read_encoded_value (struct comp_unit *unit, gdb_byte encoding,
>     {
>     case DW_EH_PE_uleb128:
>       {
> -       unsigned long long value;
> +       ULONGEST value;
>        const gdb_byte *end_buf = buf + (sizeof (value) + 1) * 8 / 7;
>
>        *bytes_read_ptr += safe_read_uleb128 (buf, end_buf, &value) - buf;
> @@ -1645,7 +1645,7 @@ read_encoded_value (struct comp_unit *unit, gdb_byte encoding,
>       return (base + bfd_get_64 (unit->abfd, (bfd_byte *) buf));
>     case DW_EH_PE_sleb128:
>       {
> -       long long value;
> +       LONGEST value;
>        const gdb_byte *end_buf = buf + (sizeof (value) + 1) * 8 / 7;
>
>        *bytes_read_ptr += safe_read_sleb128 (buf, end_buf, &value) - buf;
> @@ -1830,8 +1830,8 @@ decode_frame_entry_1 (struct comp_unit *unit, const gdb_byte *start,
>   int dwarf64_p;
>   ULONGEST cie_id;
>   ULONGEST cie_pointer;
> -  long long sleb128;
> -  unsigned long long uleb128;
> +  LONGEST sleb128;
> +  ULONGEST uleb128;
>
>   buf = start;
>   length = read_initial_length (unit->abfd, buf, &bytes_read);
> @@ -1978,7 +1978,7 @@ decode_frame_entry_1 (struct comp_unit *unit, const gdb_byte *start,
>       cie->saw_z_augmentation = (*augmentation == 'z');
>       if (cie->saw_z_augmentation)
>        {
> -         unsigned long long length;
> +         ULONGEST length;
>
>          buf = gdb_read_uleb128 (buf, end, &length);
>          if (buf == NULL)
> @@ -2095,7 +2095,7 @@ decode_frame_entry_1 (struct comp_unit *unit, const gdb_byte *start,
>         can skip the whole thing.  */
>       if (fde->cie->saw_z_augmentation)
>        {
> -         unsigned long long length;
> +         ULONGEST length;
>
>          buf = gdb_read_uleb128 (buf, end, &length);
>          if (buf == NULL)
> diff --git a/gdb/dwarf2expr.c b/gdb/dwarf2expr.c
> index 80c6e17..fc29637 100644
> --- a/gdb/dwarf2expr.c
> +++ b/gdb/dwarf2expr.c
> @@ -373,7 +373,7 @@ dwarf_expr_eval (struct dwarf_expr_context *ctx, const gdb_byte *addr,
>
>  const gdb_byte *
>  safe_read_uleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
> -                  unsigned long long *r)
> +                  ULONGEST *r)
>  {
>   buf = gdb_read_uleb128 (buf, buf_end, r);
>   if (buf == NULL)
> @@ -385,7 +385,7 @@ safe_read_uleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
>
>  const gdb_byte *
>  safe_read_sleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
> -                  long long *r)
> +                  LONGEST *r)
>  {
>   buf = gdb_read_sleb128 (buf, buf_end, r);
>   if (buf == NULL)
> @@ -465,7 +465,7 @@ dwarf_get_base_type (struct dwarf_expr_context *ctx, cu_offset die, int size)
>  int
>  dwarf_block_to_dwarf_reg (const gdb_byte *buf, const gdb_byte *buf_end)
>  {
> -  unsigned long long dwarf_reg;
> +  ULONGEST dwarf_reg;
>
>   if (buf_end <= buf)
>     return -1;
> @@ -509,8 +509,8 @@ int
>  dwarf_block_to_dwarf_reg_deref (const gdb_byte *buf, const gdb_byte *buf_end,
>                                CORE_ADDR *deref_size_return)
>  {
> -  unsigned long long dwarf_reg;
> -  long long offset;
> +  ULONGEST dwarf_reg;
> +  LONGEST offset;
>
>   if (buf_end <= buf)
>     return -1;
> @@ -568,7 +568,7 @@ int
>  dwarf_block_to_fb_offset (const gdb_byte *buf, const gdb_byte *buf_end,
>                          CORE_ADDR *fb_offset_return)
>  {
> -  long long fb_offset;
> +  LONGEST fb_offset;
>
>   if (buf_end <= buf)
>     return 0;
> @@ -595,8 +595,8 @@ int
>  dwarf_block_to_sp_offset (struct gdbarch *gdbarch, const gdb_byte *buf,
>                          const gdb_byte *buf_end, CORE_ADDR *sp_offset_return)
>  {
> -  unsigned long long dwarf_reg;
> -  long long sp_offset;
> +  ULONGEST dwarf_reg;
> +  LONGEST sp_offset;
>
>   if (buf_end <= buf)
>     return 0;
> @@ -665,8 +665,8 @@ execute_stack_op (struct dwarf_expr_context *ctx,
>         This is just an optimization, so it's always ok to punt
>         and leave this as 0.  */
>       int in_stack_memory = 0;
> -      unsigned long long uoffset, reg;
> -      long long offset;
> +      ULONGEST uoffset, reg;
> +      LONGEST offset;
>       struct value *result_val = NULL;
>
>       /* The DWARF expression might have a bug causing an infinite
> @@ -839,7 +839,7 @@ execute_stack_op (struct dwarf_expr_context *ctx,
>
>        case DW_OP_implicit_value:
>          {
> -           unsigned long long len;
> +           ULONGEST len;
>
>            op_ptr = safe_read_uleb128 (op_ptr, op_end, &len);
>            if (op_ptr + len > op_end)
> @@ -860,7 +860,7 @@ execute_stack_op (struct dwarf_expr_context *ctx,
>
>        case DW_OP_GNU_implicit_pointer:
>          {
> -           long long len;
> +           LONGEST len;
>
>            if (ctx->ref_addr_size == -1)
>              error (_("DWARF-2 expression error: DW_OP_GNU_implicit_pointer "
> @@ -1291,7 +1291,7 @@ execute_stack_op (struct dwarf_expr_context *ctx,
>
>         case DW_OP_piece:
>           {
> -            unsigned long long size;
> +            ULONGEST size;
>
>             /* Record the piece.  */
>             op_ptr = safe_read_uleb128 (op_ptr, op_end, &size);
> @@ -1308,7 +1308,7 @@ execute_stack_op (struct dwarf_expr_context *ctx,
>
>        case DW_OP_bit_piece:
>          {
> -           unsigned long long size, offset;
> +           ULONGEST size, offset;
>
>             /* Record the piece.  */
>            op_ptr = safe_read_uleb128 (op_ptr, op_end, &size);
> @@ -1354,7 +1354,7 @@ execute_stack_op (struct dwarf_expr_context *ctx,
>
>        case DW_OP_GNU_entry_value:
>          {
> -           unsigned long long len;
> +           ULONGEST len;
>            int dwarf_reg;
>            CORE_ADDR deref_size;
>
> diff --git a/gdb/dwarf2expr.h b/gdb/dwarf2expr.h
> index 82a5a93..57fe39e 100644
> --- a/gdb/dwarf2expr.h
> +++ b/gdb/dwarf2expr.h
> @@ -311,9 +311,9 @@ int dwarf_block_to_sp_offset (struct gdbarch *gdbarch, const gdb_byte *buf,
>
>  static inline const gdb_byte *
>  gdb_read_uleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
> -                 unsigned long long *r)
> +                 ULONGEST *r)
>  {
> -  size_t bytes_read = read_uleb128_to_ull (buf, buf_end, r);
> +  size_t bytes_read = read_uleb128_to_ull (buf, buf_end, (unsigned long long *) r);
>
>   if (bytes_read == 0)
>     return NULL;
> @@ -322,9 +322,9 @@ gdb_read_uleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
>
>  static inline const gdb_byte *
>  gdb_read_sleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
> -                 long long *r)
> +                 LONGEST *r)
>  {
> -  size_t bytes_read = read_sleb128_to_ll (buf, buf_end, r);
> +  size_t bytes_read = read_sleb128_to_ll (buf, buf_end, (long long *) r);
>
>   if (bytes_read == 0)
>     return NULL;
> @@ -343,11 +343,11 @@ gdb_skip_leb128 (const gdb_byte *buf, const gdb_byte *buf_end)
>
>  extern const gdb_byte *safe_read_uleb128 (const gdb_byte *buf,
>                                          const gdb_byte *buf_end,
> -                                         unsigned long long *r);
> +                                         ULONGEST *r);
>
>  extern const gdb_byte *safe_read_sleb128 (const gdb_byte *buf,
>                                          const gdb_byte *buf_end,
> -                                         long long *r);
> +                                         LONGEST *r);
>
>  extern const gdb_byte *safe_skip_leb128 (const gdb_byte *buf,
>                                         const gdb_byte *buf_end);
> diff --git a/gdb/dwarf2loc.c b/gdb/dwarf2loc.c
> index 9bd7741..14af020 100644
> --- a/gdb/dwarf2loc.c
> +++ b/gdb/dwarf2loc.c
> @@ -139,7 +139,7 @@ decode_debug_loc_dwo_addresses (struct dwarf2_per_cu_data *per_cu,
>                                const gdb_byte **new_ptr,
>                                CORE_ADDR *low, CORE_ADDR *high)
>  {
> -  unsigned long long low_index, high_index;
> +  ULONGEST low_index, high_index;
>
>   if (loc_ptr == buf_end)
>     return DEBUG_LOC_BUFFER_OVERFLOW;
> @@ -2566,8 +2566,8 @@ dwarf2_compile_expr_to_ax (struct agent_expr *expr, struct axs_value *loc,
>   while (op_ptr < op_end)
>     {
>       enum dwarf_location_atom op = *op_ptr;
> -      unsigned long long uoffset, reg;
> -      long long offset;
> +      ULONGEST uoffset, reg;
> +      LONGEST offset;
>       int i;
>
>       offsets[op_ptr - base] = expr->len;
> @@ -2725,7 +2725,7 @@ dwarf2_compile_expr_to_ax (struct agent_expr *expr, struct axs_value *loc,
>
>        case DW_OP_implicit_value:
>          {
> -           unsigned long long len;
> +           ULONGEST len;
>
>            op_ptr = safe_read_uleb128 (op_ptr, op_end, &len);
>            if (op_ptr + len > op_end)
> @@ -3075,7 +3075,7 @@ dwarf2_compile_expr_to_ax (struct agent_expr *expr, struct axs_value *loc,
>         case DW_OP_piece:
>        case DW_OP_bit_piece:
>          {
> -           unsigned long long size, offset;
> +           ULONGEST size, offset;
>
>            if (op_ptr - 1 == previous_piece)
>              error (_("Cannot translate empty pieces to agent expressions"));
> @@ -3267,7 +3267,7 @@ locexpr_describe_location_piece (struct symbol *symbol, struct ui_file *stream,
>     }
>   else if (data[0] == DW_OP_regx)
>     {
> -      unsigned long long reg;
> +      ULONGEST reg;
>
>       data = safe_read_uleb128 (data + 1, end, &reg);
>       fprintf_filtered (stream, _("a variable in $%s"),
> @@ -3278,10 +3278,10 @@ locexpr_describe_location_piece (struct symbol *symbol, struct ui_file *stream,
>       struct block *b;
>       struct symbol *framefunc;
>       int frame_reg = 0;
> -      long long frame_offset;
> +      LONGEST frame_offset;
>       const gdb_byte *base_data, *new_data, *save_data = data;
>       size_t base_size;
> -      long long base_offset = 0;
> +      LONGEST base_offset = 0;
>
>       new_data = safe_read_sleb128 (data + 1, end, &frame_offset);
>       if (!piece_end_p (new_data, end))
> @@ -3335,7 +3335,7 @@ locexpr_describe_location_piece (struct symbol *symbol, struct ui_file *stream,
>   else if (data[0] >= DW_OP_breg0 && data[0] <= DW_OP_breg31
>           && piece_end_p (data, end))
>     {
> -      long long offset;
> +      LONGEST offset;
>
>       data = safe_read_sleb128 (data + 1, end, &offset);
>
> @@ -3409,8 +3409,8 @@ disassemble_dwarf_expression (struct ui_file *stream,
>             || (data[0] != DW_OP_piece && data[0] != DW_OP_bit_piece)))
>     {
>       enum dwarf_location_atom op = *data++;
> -      unsigned long long ul;
> -      long long l;
> +      ULONGEST ul;
> +      LONGEST l;
>       const char *name;
>
>       name = get_DW_OP_name (op);
> @@ -3630,7 +3630,7 @@ disassemble_dwarf_expression (struct ui_file *stream,
>
>        case DW_OP_bit_piece:
>          {
> -           unsigned long long offset;
> +           ULONGEST offset;
>
>            data = safe_read_uleb128 (data, end, &ul);
>            data = safe_read_uleb128 (data, end, &offset);
> @@ -3685,7 +3685,7 @@ disassemble_dwarf_expression (struct ui_file *stream,
>
>        case DW_OP_GNU_regval_type:
>          {
> -           unsigned long long reg;
> +           ULONGEST reg;
>            cu_offset type_die;
>            struct type *type;
>
> @@ -3794,7 +3794,7 @@ locexpr_describe_location_1 (struct symbol *symbol, CORE_ADDR addr,
>            fprintf_filtered (stream, "   ");
>          if (data[0] == DW_OP_piece)
>            {
> -             unsigned long long bytes;
> +             ULONGEST bytes;
>
>              data = safe_read_uleb128 (data + 1, end, &bytes);
>
> @@ -3807,7 +3807,7 @@ locexpr_describe_location_1 (struct symbol *symbol, CORE_ADDR addr,
>            }
>          else if (data[0] == DW_OP_bit_piece)
>            {
> -             unsigned long long bits, offset;
> +             ULONGEST bits, offset;
>
>              data = safe_read_uleb128 (data + 1, end, &bits);
>              data = safe_read_uleb128 (data, end, &offset);


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-23  7:10   ` Doug Evans
@ 2012-05-23  7:27     ` Doug Evans
  2012-05-23  8:19       ` Pierre Muller
                         ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Doug Evans @ 2012-05-23  7:27 UTC (permalink / raw)
  To: gdb-patches; +Cc: Sergio Durigan Junior

Hmmm, there's more than a few uses of long long in gdb (not all
conditioned on CC_HAS_LONG_LONG, though most are in target files) and
gdbserver (I was pretty sure I checked at the time).

So is this ARI check outdated?

I'm happy to change the code as necessary.
If we can't use C++ can we at least use a modern C?  1/2 :-)

On Wed, May 23, 2012 at 12:10 AM, Doug Evans <dje@google.com> wrote:
> Well, blech.
> src/include/leb128.h uses long long per request, so that's what I used here.
> src/include/anything obviously cannot use LONGEST/ULONGEST.
>
> Are long long's really verboten?
>
> I suppose I could create a gdb-leb128.h that used LONGEST/ULONGEST,
> but blech.
>
>
> On Tue, May 22, 2012 at 9:17 PM, Sergio Durigan Junior
> <sergiodj@redhat.com> wrote:
>> WDYT about the following patch?  I would like you to take a look at the
>> gdb/dwarf2expr.h's castings that I had to make in order to get the
>> compilation right.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* RE: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-23  7:27     ` Doug Evans
@ 2012-05-23  8:19       ` Pierre Muller
  2012-05-23 14:45       ` Sergio Durigan Junior
       [not found]       ` <4fbc9d77.0853b40a.641e.ffff90dbSMTPIN_ADDED@mx.google.com>
  2 siblings, 0 replies; 23+ messages in thread
From: Pierre Muller @ 2012-05-23  8:19 UTC (permalink / raw)
  To: 'Doug Evans', gdb-patches

  As a possible ARI maintainer I would like to clarify
things here:
  "long long" and "unsigned long long"
are used in lots of native files, and they are 
OK in those context.

  In fact, one of the improvements I have in mind is
to restrain some ARI rules, like this one to
GDB common files.
  This would mean that files that are
only used for specific native targets would be allowed to use
"long long" without generating a warning.

  The use of "long long" and "unsigned long long"
is discouraged as it is not available in all C compilers
if I understood the definitions in defs.h around line 112.

 Another possible use of LONGEST and ULONGEST 
is also to be able to cope with 128-bit integers if these
are used in GDB later.

Pierre Muller


> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Doug Evans
> Envoyé : mercredi 23 mai 2012 09:28
> À : gdb-patches
> Cc : Sergio Durigan Junior
> Objet : Re: New ARI warning Wed May 23 01:55:03 UTC 2012
> 
> Hmmm, there's more than a few uses of long long in gdb (not all
> conditioned on CC_HAS_LONG_LONG, though most are in target files) and
> gdbserver (I was pretty sure I checked at the time).
> 
> So is this ARI check outdated?
> 
> I'm happy to change the code as necessary.
> If we can't use C++ can we at least use a modern C?  1/2 :-)
> 
> On Wed, May 23, 2012 at 12:10 AM, Doug Evans <dje@google.com> wrote:
> > Well, blech.
> > src/include/leb128.h uses long long per request, so that's what I used
> here.
> > src/include/anything obviously cannot use LONGEST/ULONGEST.
> >
> > Are long long's really verboten?
> >
> > I suppose I could create a gdb-leb128.h that used LONGEST/ULONGEST,
> > but blech.
> >
> >
> > On Tue, May 22, 2012 at 9:17 PM, Sergio Durigan Junior
> > <sergiodj@redhat.com> wrote:
> >> WDYT about the following patch?  I would like you to take a look at the
> >> gdb/dwarf2expr.h's castings that I had to make in order to get the
> >> compilation right.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-23  7:27     ` Doug Evans
  2012-05-23  8:19       ` Pierre Muller
@ 2012-05-23 14:45       ` Sergio Durigan Junior
       [not found]       ` <4fbc9d77.0853b40a.641e.ffff90dbSMTPIN_ADDED@mx.google.com>
  2 siblings, 0 replies; 23+ messages in thread
From: Sergio Durigan Junior @ 2012-05-23 14:45 UTC (permalink / raw)
  To: Doug Evans; +Cc: gdb-patches

On Wednesday, May 23 2012, Doug Evans wrote:

> Hmmm, there's more than a few uses of long long in gdb (not all
> conditioned on CC_HAS_LONG_LONG, though most are in target files) and
> gdbserver (I was pretty sure I checked at the time).
>
> So is this ARI check outdated?

I saw this, too.

-- 
Sergio


^ permalink raw reply	[flat|nested] 23+ messages in thread

[parent not found: <4fbc9d77.0853b40a.641e.ffff90dbSMTPIN_ADDED@mx.google.com>]

* RE: New ARI warning Wed May 23 01:55:03 UTC 2012
       [not found]       ` <4fbc9d77.0853b40a.641e.ffff90dbSMTPIN_ADDED@mx.google.com>
@ 2012-05-23 14:46         ` Doug Evans
  2012-05-23 15:01           ` Doug Evans
  2012-05-24 18:55           ` Tom Tromey
  0 siblings, 2 replies; 23+ messages in thread
From: Doug Evans @ 2012-05-23 14:46 UTC (permalink / raw)
  To: Pierre Muller; +Cc: gdb-patches

On May 23, 2012 1:19 AM, "Pierre Muller"
<pierre.muller@ics-cnrs.unistra.fr> wrote:
>
>  As a possible ARI maintainer I would like to clarify
> things here:
>  "long long" and "unsigned long long"
> are used in lots of native files, and they are
> OK in those context.
>
>  In fact, one of the improvements I have in mind is
> to restrain some ARI rules, like this one to
> GDB common files.
>  This would mean that files that are
> only used for specific native targets would be allowed to use
> "long long" without generating a warning.

I'm not comfortable with such rules, fwiw.
It's just more arcane baggage to have to remember and follow.

>
>  The use of "long long" and "unsigned long long"
> is discouraged as it is not available in all C compilers
> if I understood the definitions in defs.h around line 112.

I wonder how old that is.

>  Another possible use of LONGEST and ULONGEST
> is also to be able to cope with 128-bit integers if these
> are used in GDB later.

Think bigger.
LONGEST,ULONGEST are gdb-specific, and there is nothing in reading
leb128 values that is gdb-specific.

Plus a lot of code uses them with the assumption that they're 64 bits,
having them be 128 bits is probably not workable.

We've been debating whether to move to C++, and yet we can't even move
to C99. :-(


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-23 14:46         ` Doug Evans
@ 2012-05-23 15:01           ` Doug Evans
  2012-05-23 15:27             ` Pedro Alves
  2012-05-24 18:55           ` Tom Tromey
  1 sibling, 1 reply; 23+ messages in thread
From: Doug Evans @ 2012-05-23 15:01 UTC (permalink / raw)
  To: Pierre Muller; +Cc: gdb-patches

On Wed, May 23, 2012 at 7:46 AM, Doug Evans <dje@google.com> wrote:
> On May 23, 2012 1:19 AM, "Pierre Muller"
> <pierre.muller@ics-cnrs.unistra.fr> wrote:
>>
>>  As a possible ARI maintainer I would like to clarify
>> things here:
>>  "long long" and "unsigned long long"
>> are used in lots of native files, and they are
>> OK in those context.
>>
>>  In fact, one of the improvements I have in mind is
>> to restrain some ARI rules, like this one to
>> GDB common files.
>>  This would mean that files that are
>> only used for specific native targets would be allowed to use
>> "long long" without generating a warning.
>
> I'm not comfortable with such rules, fwiw.
> It's just more arcane baggage to have to remember and follow.
>
>>
>>  The use of "long long" and "unsigned long long"
>> is discouraged as it is not available in all C compilers
>> if I understood the definitions in defs.h around line 112.
>
> I wonder how old that is.
>
>>  Another possible use of LONGEST and ULONGEST
>> is also to be able to cope with 128-bit integers if these
>> are used in GDB later.
>
> Think bigger.
> LONGEST,ULONGEST are gdb-specific, and there is nothing in reading
> leb128 values that is gdb-specific.
>
> Plus a lot of code uses them with the assumption that they're 64 bits,
> having them be 128 bits is probably not workable.
>
> We've been debating whether to move to C++, and yet we can't even move
> to C99. :-(

For reference sake,
An alternative is to use {,u}int64_t, does ARI have any rule on them?
It's been in use in at least findcmd.c since gdb 7.0 [IIUC]
(perhaps errantly, but nevertheless ...).


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-23 15:01           ` Doug Evans
@ 2012-05-23 15:27             ` Pedro Alves
  0 siblings, 0 replies; 23+ messages in thread
From: Pedro Alves @ 2012-05-23 15:27 UTC (permalink / raw)
  To: Doug Evans; +Cc: Pierre Muller, gdb-patches

On 05/23/2012 04:01 PM, Doug Evans wrote:

> For reference sake,
> An alternative is to use {,u}int64_t, does ARI have any rule on them?

If there is, it's outdated.  We pick up stdint.h/inttypes.h from gnulib, so
those types are now available on all hosts.  If not, it's a gnulib problem.
I suggest to use those types, because libiberty itself has recently
began assuming uintptr_t through either stdint.h or inttypes.h is available.

<http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00292.html>

I see no reason to consider 128 types in a libiberty header/interface at
this point.  It'll be a long while (decades?) before that could be
considered portable.

> It's been in use in at least findcmd.c since gdb 7.0 [IIUC]
> (perhaps errantly, but nevertheless ...).

-- 
Pedro Alves

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-23 14:46         ` Doug Evans
  2012-05-23 15:01           ` Doug Evans
@ 2012-05-24 18:55           ` Tom Tromey
  2012-05-28 20:44             ` Mark Kettenis
  1 sibling, 1 reply; 23+ messages in thread
From: Tom Tromey @ 2012-05-24 18:55 UTC (permalink / raw)
  To: Doug Evans; +Cc: Pierre Muller, gdb-patches

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> We've been debating whether to move to C++, and yet we can't even move
Doug> to C99. :-(

In this particular case I think I somewhat prefer the sized types.

That said, I wouldn't mind moving to C99.  Of course, it is easy for me
to say; the important question is whether anybody is building on hosts
that don't have C99 compilers.

Tom

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-24 18:55           ` Tom Tromey
@ 2012-05-28 20:44             ` Mark Kettenis
  2012-05-28 21:59               ` Joel Brobecker
                                 ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Mark Kettenis @ 2012-05-28 20:44 UTC (permalink / raw)
  To: tromey; +Cc: dje, pierre.muller, gdb-patches

> From: Tom Tromey <tromey@redhat.com>
> 
> >>>>> "Doug" == Doug Evans <dje@google.com> writes:
> 
> Doug> We've been debating whether to move to C++, and yet we can't even move
> Doug> to C99. :-(
> 
> In this particular case I think I somewhat prefer the sized types.
> 
> That said, I wouldn't mind moving to C99.  Of course, it is easy for me
> to say; the important question is whether anybody is building on hosts
> that don't have C99 compilers.

OpenBSD/vax, OpenBSD/m68k and OpenBSD/m88k are still stuck with GCC
2.95, which is almost, but not quite C99.  However, it's been ages
since I've last built GDB on any of those platforms.  So it's probably
time to stop caring about those platforms.  I fear that GDB has become
too bloated to be able to build it a typical machine that runs these
specific OpenBSD versions.  But even GCC 2.95 supports long long as an
extension to C90.

So I'd have no objection to requiring C99, except for one
style-related issue.  I really, really hate mixing declarations with
code (something that C99 started to allow).  So if we switch to
requiring C99, I think we should add a rule to the coding standards
that variables may only be declared at the start of a block.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-28 20:44             ` Mark Kettenis
@ 2012-05-28 21:59               ` Joel Brobecker
  2012-05-29 13:29               ` Maciej W. Rozycki
  2012-06-22 16:05               ` Tom Tromey
  2 siblings, 0 replies; 23+ messages in thread
From: Joel Brobecker @ 2012-05-28 21:59 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: tromey, dje, pierre.muller, gdb-patches

> OpenBSD/vax, OpenBSD/m68k and OpenBSD/m88k are still stuck with GCC
> 2.95, which is almost, but not quite C99.  However, it's been ages
> since I've last built GDB on any of those platforms.  So it's probably
> time to stop caring about those platforms.  I fear that GDB has become
> too bloated to be able to build it a typical machine that runs these
> specific OpenBSD versions.  But even GCC 2.95 supports long long as an
> extension to C90.
>
> So I'd have no objection to requiring C99

Instead of unilaterally allowing C99, can we instead explicitly
define which parts of C99 we allow, and list them specifically?

> , except for one
> style-related issue.  I really, really hate mixing declarations with
> code (something that C99 started to allow).  So if we switch to
> requiring C99, I think we should add a rule to the coding standards
> that variables may only be declared at the start of a block.

I agree with this recommendation.

-- 
Joel


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-28 20:44             ` Mark Kettenis
  2012-05-28 21:59               ` Joel Brobecker
@ 2012-05-29 13:29               ` Maciej W. Rozycki
  2012-06-22 16:05               ` Tom Tromey
  2 siblings, 0 replies; 23+ messages in thread
From: Maciej W. Rozycki @ 2012-05-29 13:29 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: Tom Tromey, dje, pierre.muller, gdb-patches

On Mon, 28 May 2012, Mark Kettenis wrote:

> OpenBSD/vax, OpenBSD/m68k and OpenBSD/m88k are still stuck with GCC
> 2.95, which is almost, but not quite C99.  However, it's been ages
> since I've last built GDB on any of those platforms.  So it's probably
> time to stop caring about those platforms.  I fear that GDB has become
> too bloated to be able to build it a typical machine that runs these
> specific OpenBSD versions.  But even GCC 2.95 supports long long as an
> extension to C90.

 Interesting, I found GCC 4.1.2 working reasonably well for the VAX 
target, other versions are probably OK too -- why did OpenBSD stick to 
such an old version for that target?

 Anyway, I reckon GCC used to support long long even before that, although 
there might have been issues.

> So I'd have no objection to requiring C99, except for one
> style-related issue.  I really, really hate mixing declarations with
> code (something that C99 started to allow).  So if we switch to
> requiring C99, I think we should add a rule to the coding standards
> that variables may only be declared at the start of a block.

 FWIW, I concur.  I find them confusing and easy to avoid.

  Maciej


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-28 20:44             ` Mark Kettenis
  2012-05-28 21:59               ` Joel Brobecker
  2012-05-29 13:29               ` Maciej W. Rozycki
@ 2012-06-22 16:05               ` Tom Tromey
  2012-06-22 17:19                 ` Joel Brobecker
  2012-06-26 11:51                 ` Mark Kettenis
  2 siblings, 2 replies; 23+ messages in thread
From: Tom Tromey @ 2012-06-22 16:05 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: dje, pierre.muller, gdb-patches

>>>>> "Mark" == Mark Kettenis <mark.kettenis@xs4all.nl> writes:

Mark> So I'd have no objection to requiring C99, except for one
Mark> style-related issue.  I really, really hate mixing declarations with
Mark> code (something that C99 started to allow).  So if we switch to
Mark> requiring C99, I think we should add a rule to the coding standards
Mark> that variables may only be declared at the start of a block.

If there is no warning for it, then uses will slip in.

Tom

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-06-22 16:05               ` Tom Tromey
@ 2012-06-22 17:19                 ` Joel Brobecker
  2012-06-22 17:31                   ` Joel Brobecker
  2012-06-26 13:15                   ` Mark Kettenis
  2012-06-26 11:51                 ` Mark Kettenis
  1 sibling, 2 replies; 23+ messages in thread
From: Joel Brobecker @ 2012-06-22 17:19 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Mark Kettenis, dje, pierre.muller, gdb-patches

> Mark> So I'd have no objection to requiring C99, except for one
> Mark> style-related issue.  I really, really hate mixing declarations with
> Mark> code (something that C99 started to allow).  So if we switch to
> Mark> requiring C99, I think we should add a rule to the coding standards
> Mark> that variables may only be declared at the start of a block.
> 
> If there is no warning for it, then uses will slip in.

Here is a patch that adds -Wdeclaration-after-statement to the list
of compiler warnings...

Tested on x86_64-linux by rebuilding the native compiler with
--enable-targets=all.

gdb/ChangeLog:

        * configure.ac (build_warnings): Add -Wdeclaration-after-statement.
        * configure: Regenerate.

OK to commit?

Thanks,
-- 
Joel


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-06-22 17:19                 ` Joel Brobecker
@ 2012-06-22 17:31                   ` Joel Brobecker
  2012-06-22 17:41                     ` Tom Tromey
  2012-06-26 13:15                   ` Mark Kettenis
  1 sibling, 1 reply; 23+ messages in thread
From: Joel Brobecker @ 2012-06-22 17:31 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Mark Kettenis, dje, pierre.muller, gdb-patches

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

(deep breath...)

> Tested on x86_64-linux by rebuilding the native compiler with
> --enable-targets=all.
> 
> gdb/ChangeLog:
> 
>         * configure.ac (build_warnings): Add -Wdeclaration-after-statement.
>         * configure: Regenerate.

Patch attached, this time.

-- 
Joel

[-- Attachment #2: 0001-Add-Wdeclaration-after-statement-to-list-of-compiler.patch --]
[-- Type: text/x-diff, Size: 1598 bytes --]

From 6dd065b6a22bab9c916ce716faf005ce368c2d8e Mon Sep 17 00:00:00 2001
From: Joel Brobecker <brobecker@adacore.com>
Date: Fri, 22 Jun 2012 10:15:53 -0700
Subject: [PATCH] Add -Wdeclaration-after-statement to list of compiler warnings

gdb/ChangeLog:

        * configure.ac (build_warnings): Add -Wdeclaration-after-statement.
        * configure: Regenerate.
---
 gdb/configure    |    3 ++-
 gdb/configure.ac |    3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/gdb/configure b/gdb/configure
index 1ea4ee9..b0b5d11 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -12386,7 +12386,8 @@ fi
 build_warnings="-Wall -Wdeclaration-after-statement -Wpointer-arith \
 -Wformat-nonliteral -Wno-pointer-sign \
 -Wno-unused -Wunused-value -Wunused-function \
--Wno-switch -Wno-char-subscripts -Wmissing-prototypes"
+-Wno-switch -Wno-char-subscripts -Wmissing-prototypes \
+-Wdeclaration-after-statement"
 
 # Enable -Wno-format by default when using gcc on mingw since many
 # GCC versions complain about %I64.
diff --git a/gdb/configure.ac b/gdb/configure.ac
index 5771825..3fdeb89 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -1867,7 +1867,8 @@ fi
 build_warnings="-Wall -Wdeclaration-after-statement -Wpointer-arith \
 -Wformat-nonliteral -Wno-pointer-sign \
 -Wno-unused -Wunused-value -Wunused-function \
--Wno-switch -Wno-char-subscripts -Wmissing-prototypes"
+-Wno-switch -Wno-char-subscripts -Wmissing-prototypes \
+-Wdeclaration-after-statement"
 
 # Enable -Wno-format by default when using gcc on mingw since many
 # GCC versions complain about %I64.
-- 
1.7.1


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-06-22 17:31                   ` Joel Brobecker
@ 2012-06-22 17:41                     ` Tom Tromey
  2012-06-22 19:02                       ` Joel Brobecker
  0 siblings, 1 reply; 23+ messages in thread
From: Tom Tromey @ 2012-06-22 17:41 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Mark Kettenis, dje, pierre.muller, gdb-patches

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

>> * configure.ac (build_warnings): Add -Wdeclaration-after-statement.
>> * configure: Regenerate.

Yes, ok.  Thanks; I hadn't realized there was a flag for this already :)

Discussion on irc pointed out that this is still allowed:

    for (int i = 0; ...)

I think this doesn't suffer from the readability problems that
declarations in the code generally do; and in fact usually makes the
code cleaner, by restricting the scope of the loop variable.

How about we flip the switch to C99 for 7.6?

Tom

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-06-22 17:41                     ` Tom Tromey
@ 2012-06-22 19:02                       ` Joel Brobecker
  2012-06-25 19:59                         ` Doug Evans
  2012-06-26 13:31                         ` Mark Kettenis
  0 siblings, 2 replies; 23+ messages in thread
From: Joel Brobecker @ 2012-06-22 19:02 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Mark Kettenis, dje, pierre.muller, gdb-patches

> >> * configure.ac (build_warnings): Add -Wdeclaration-after-statement.
> >> * configure: Regenerate.
> 
> Yes, ok.  Thanks; I hadn't realized there was a flag for this already :)

Thanks, checked in.

> Discussion on irc pointed out that this is still allowed:
> 
>     for (int i = 0; ...)
> 
> I think this doesn't suffer from the readability problems that
> declarations in the code generally do; and in fact usually makes the
> code cleaner, by restricting the scope of the loop variable.

Agreed.

Note that this is only going to be accepted if we compile in
C99 mode, I think.  Otherwise, you'll get a warning which is
unrelated declarations being used after statements.

    error: 'for' loop initial declarations are only allowed in C99 mode

> How about we flip the switch to C99 for 7.6?

Sounds good to me. Do we want to be exclusive, rather than inclusive?
In other words, say: The following C99 constructs are allowed, and
maintain that list, rather that allow all of C99, and then list
the features not allowed. I understand that some features are still
not implemented (or portable?).

-- 
Joel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-06-22 19:02                       ` Joel Brobecker
@ 2012-06-25 19:59                         ` Doug Evans
  2012-06-26 13:31                         ` Mark Kettenis
  1 sibling, 0 replies; 23+ messages in thread
From: Doug Evans @ 2012-06-25 19:59 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Tom Tromey, Mark Kettenis, pierre.muller, gdb-patches

On Fri, Jun 22, 2012 at 12:02 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Tom Tromey wrote:
>> How about we flip the switch to C99 for 7.6?
>
> Sounds good to me. Do we want to be exclusive, rather than inclusive?
> In other words, say: The following C99 constructs are allowed, and
> maintain that list, rather that allow all of C99, and then list
> the features not allowed. I understand that some features are still
> not implemented (or portable?).

Which would be easier?
It feels like listing the allowed constructs would work best.
[We can still add text to list/discuss what's disallowed, but separately.]


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-06-22 19:02                       ` Joel Brobecker
  2012-06-25 19:59                         ` Doug Evans
@ 2012-06-26 13:31                         ` Mark Kettenis
  1 sibling, 0 replies; 23+ messages in thread
From: Mark Kettenis @ 2012-06-26 13:31 UTC (permalink / raw)
  To: brobecker; +Cc: tromey, mark.kettenis, dje, pierre.muller, gdb-patches

> Date: Fri, 22 Jun 2012 12:02:28 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> > >> * configure.ac (build_warnings): Add -Wdeclaration-after-statement.
> > >> * configure: Regenerate.
> > 
> > Yes, ok.  Thanks; I hadn't realized there was a flag for this already :)
> 
> Thanks, checked in.
> 
> > Discussion on irc pointed out that this is still allowed:
> > 
> >     for (int i = 0; ...)
> > 
> > I think this doesn't suffer from the readability problems that
> > declarations in the code generally do; and in fact usually makes the
> > code cleaner, by restricting the scope of the loop variable.
> 
> Agreed.
> 
> Note that this is only going to be accepted if we compile in
> C99 mode, I think.  Otherwise, you'll get a warning which is
> unrelated declarations being used after statements.
> 
>     error: 'for' loop initial declarations are only allowed in C99 mode
> 
> > How about we flip the switch to C99 for 7.6?
> 
> Sounds good to me. Do we want to be exclusive, rather than inclusive?
> In other words, say: The following C99 constructs are allowed, and
> maintain that list, rather that allow all of C99, and then list
> the features not allowed. I understand that some features are still
> not implemented (or portable?).

I'm not aware of any C99 language features that aren't widely
implemented by the halfway modern compilers.  But there might be some
obscure corners of the standard that I'm not familiar with.  I think
only the approach of listing features that we don't allow makes sense.
That list should be very short.

C99 library functions and header files are a different matter though.
Those may not be available on older systems.  We can only use those if
we provide proper replacement functions (e.g. gnulib).


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-06-22 17:19                 ` Joel Brobecker
  2012-06-22 17:31                   ` Joel Brobecker
@ 2012-06-26 13:15                   ` Mark Kettenis
  1 sibling, 0 replies; 23+ messages in thread
From: Mark Kettenis @ 2012-06-26 13:15 UTC (permalink / raw)
  To: brobecker; +Cc: tromey, mark.kettenis, dje, pierre.muller, gdb-patches

> Date: Fri, 22 Jun 2012 10:19:22 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> > Mark> So I'd have no objection to requiring C99, except for one
> > Mark> style-related issue.  I really, really hate mixing declarations with
> > Mark> code (something that C99 started to allow).  So if we switch to
> > Mark> requiring C99, I think we should add a rule to the coding standards
> > Mark> that variables may only be declared at the start of a block.
> > 
> > If there is no warning for it, then uses will slip in.
> 
> Here is a patch that adds -Wdeclaration-after-statement to the list
> of compiler warnings...

Oh, there *is* a flag for this?  I looked for it but didn't find it...

> Tested on x86_64-linux by rebuilding the native compiler with
> --enable-targets=all.
> 
> gdb/ChangeLog:
> 
>         * configure.ac (build_warnings): Add -Wdeclaration-after-statement.
>         * configure: Regenerate.
> 
> OK to commit?

yes, please


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-06-22 16:05               ` Tom Tromey
  2012-06-22 17:19                 ` Joel Brobecker
@ 2012-06-26 11:51                 ` Mark Kettenis
  1 sibling, 0 replies; 23+ messages in thread
From: Mark Kettenis @ 2012-06-26 11:51 UTC (permalink / raw)
  To: tromey; +Cc: mark.kettenis, dje, pierre.muller, gdb-patches

> From: Tom Tromey <tromey@redhat.com>
> Cc: dje@google.com, pierre.muller@ics-cnrs.unistra.fr,
>         gdb-patches@sourceware.org
> Date: Fri, 22 Jun 2012 10:04:39 -0600
> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
> X-XS4ALL-DNSBL-Checked: mxdrop138.xs4all.nl checked 209.132.183.28 against DNS blacklists
> X-CNFS-Analysis: v=2.0 cv=BoYqN/r5 c=1 sm=0 a=EoCpGYUz4Hoh5VNdmhp8sg==:17
> 	a=nUfg596yZbcA:10 a=6S1mYhvI0JkA:10 a=K_0WnIvp2iAA:10
> 	a=pb-PBmHuEqsA:10 a=20KFwNOVAAAA:8 a=6Xxp_h8RXR2XXjevXgMA:9
> 	a=EoCpGYUz4Hoh5VNdmhp8sg==:117
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: -0.0 () SPF_HELO_PASS, SPF_PASS
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kettenis@xs4all.nl
> 
> >>>>> "Mark" == Mark Kettenis <mark.kettenis@xs4all.nl> writes:
> 
> Mark> So I'd have no objection to requiring C99, except for one
> Mark> style-related issue.  I really, really hate mixing declarations with
> Mark> code (something that C99 started to allow).  So if we switch to
> Mark> requiring C99, I think we should add a rule to the coding standards
> Mark> that variables may only be declared at the start of a block.
> 
> If there is no warning for it, then uses will slip in.

Yes, but they already do.  All I want to make sure is that they are
"officially" considered bad style, that we try to keep an eye open for them
during patch review and that fixing them is "obviously correct".


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: New ARI warning Wed May 23 01:55:03 UTC 2012
  2012-05-23  4:18 ` Sergio Durigan Junior
  2012-05-23  7:10   ` Doug Evans
@ 2012-05-23  7:10   ` Andreas Schwab
  1 sibling, 0 replies; 23+ messages in thread
From: Andreas Schwab @ 2012-05-23  7:10 UTC (permalink / raw)
  To: Sergio Durigan Junior; +Cc: gdb-patches

Sergio Durigan Junior <sergiodj@redhat.com> writes:

> @@ -311,9 +311,9 @@ int dwarf_block_to_sp_offset (struct gdbarch *gdbarch, const gdb_byte *buf,
>  
>  static inline const gdb_byte *
>  gdb_read_uleb128 (const gdb_byte *buf, const gdb_byte *buf_end,
> -		  unsigned long long *r)
> +		  ULONGEST *r)
>  {
> -  size_t bytes_read = read_uleb128_to_ull (buf, buf_end, r);
> +  size_t bytes_read = read_uleb128_to_ull (buf, buf_end, (unsigned long long *) r);

That cannot work.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2012-06-26 13:31 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-23  1:55 New ARI warning Wed May 23 01:55:03 UTC 2012 GDB Administrator
2012-05-23  4:18 ` Sergio Durigan Junior
2012-05-23  7:10   ` Doug Evans
2012-05-23  7:27     ` Doug Evans
2012-05-23  8:19       ` Pierre Muller
2012-05-23 14:45       ` Sergio Durigan Junior
     [not found]       ` <4fbc9d77.0853b40a.641e.ffff90dbSMTPIN_ADDED@mx.google.com>
2012-05-23 14:46         ` Doug Evans
2012-05-23 15:01           ` Doug Evans
2012-05-23 15:27             ` Pedro Alves
2012-05-24 18:55           ` Tom Tromey
2012-05-28 20:44             ` Mark Kettenis
2012-05-28 21:59               ` Joel Brobecker
2012-05-29 13:29               ` Maciej W. Rozycki
2012-06-22 16:05               ` Tom Tromey
2012-06-22 17:19                 ` Joel Brobecker
2012-06-22 17:31                   ` Joel Brobecker
2012-06-22 17:41                     ` Tom Tromey
2012-06-22 19:02                       ` Joel Brobecker
2012-06-25 19:59                         ` Doug Evans
2012-06-26 13:31                         ` Mark Kettenis
2012-06-26 13:15                   ` Mark Kettenis
2012-06-26 11:51                 ` Mark Kettenis
2012-05-23  7:10   ` Andreas Schwab

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox