[PATCH] Prune useless .debug_loc entries (PR debug/43442)

[Jan Kratochvil]

Hi Jakub,

I do not have a real regression reproducer but I believe there can be one.
To give you the idea:

frag.c under the test:
------------------------------------------------------------------------------
extern void g (int a, int b, int c, int d);
extern void h (void);
extern int j (int x);
void
f (int x)
{
	int a, b, c, d;
	{
		int a1 = j (x) * 10;
		int b1 = j (x) * 20;
		int c1 = j (x) * 30;
		int d1 = j (x) * 40;
		a = a1;
		b = b1;
		c = c1;
		d = d1;
		h ();
	}
	g (a, b, c, d);
}
------------------------------------------------------------------------------
just a stub to make it executable:
------------------------------------------------------------------------------
void g (int a, int b, int c, int d) {}
void h (void) {}
int j (int x) { return x; }
extern void f (int x);
int
main (void)
{
  f (1);
  return 0;
}
------------------------------------------------------------------------------

GCC 4.5.0 HEAD with your patch produces:

 <2><85>: Abbrev Number: 6 (DW_TAG_lexical_block)
    <86>   DW_AT_ranges      : 0x0      
 <3><a6>: Abbrev Number: 5 (DW_TAG_variable)
    <a7>   DW_AT_name        : c1       
    <b0>   DW_AT_location    : 0x160    (location list)
Contents of the .debug_loc section:
    Offset   Begin    End      Expression
    00000160 000000000000003b 0000000000000043 (DW_OP_breg0: 0; DW_OP_lit30; DW_OP_mul; DW_OP_stack_value)
    00000160 0000000000000043 0000000000000089 (DW_OP_breg13: 0; DW_OP_lit30; DW_OP_mul; DW_OP_stack_value)
    00000160 <End of list>
Contents of the .debug_ranges section:
    Offset   Begin    End
    00000000 000000000000001a 000000000000002d 
    00000000 0000000000000031 000000000000003b 
    00000000 000000000000003f 0000000000000046 
    00000000 0000000000000049 000000000000004e 
    00000000 <End of list>

Your patch keeps .debug_loc the same as the range 0x43..0x89 is used by
.debug_ranges at least in some of its parts.  But when I change it to:

    00000160 000000000000003b 0000000000000043 (DW_OP_breg0: 0; DW_OP_lit30; DW_OP_mul; DW_OP_stack_value)
    00000160 0000000000000043 0000000000000046 (DW_OP_breg13: 0; DW_OP_lit30; DW_OP_mul; DW_OP_stack_value)
    00000160 0000000000000049 0000000000000089 (DW_OP_breg13: 0; DW_OP_lit30; DW_OP_mul; DW_OP_stack_value)
    00000160 <End of list>

to reduce it just to the valid ranges of .debug_ranges I get a debugging
regression:

12			int d1 = j (x) * 40;
(gdb) set can-use-hw-watchpoints 0
(gdb) watch c1
Watchpoint 2: c1
(gdb) stepi
19		g (a, b, c, d);
(gdb) info watchpoints 
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00000000004004c4 in f at frag.c:12
	breakpoint already hit 1 time
2       watchpoint     keep y                      c1
(gdb) info locals 
c = 30
d = 40
(gdb) stepi
17			h ();
(gdb) _

a regression to:

12			int d1 = j (x) * 40;
(gdb) set can-use-hw-watchpoints 0
(gdb) watch c1
Watchpoint 2: c1
(gdb) stepi
Watchpoint 2: c1

Old value = 30
New value = <value optimized out>
f (x=<value optimized out>) at frag.c:19
19		g (a, b, c, d);
(gdb) stepi
Watchpoint 2: c1

Old value = <value optimized out>
New value = 30
f (x=<value optimized out>) at frag.c:17
17			h ();
(gdb) _

The change on my local x86_64 -dA -S -g -O2 4.5.0 HEAD with your patch build:

--- frag.s-orig	2010-03-22 14:06:08.000000000 +0100
+++ frag.s	2010-03-22 14:09:03.000000000 +0100
@@ -223,6 +223,14 @@ f:
 	.byte	0x1e	# DW_OP_mul
 	.byte	0x9f	# DW_OP_stack_value
 	.quad	.LVL9-1-.Ltext0	# Location list begin address (*.LLST6)
+	.quad	.LVL9-1-.Ltext0+3	# Location list end address (*.LLST6)
+	.value	0x5	# Location expression size
+	.byte	0x7d	# DW_OP_breg13
+	.sleb128 0
+	.byte	0x4e	# DW_OP_lit30
+	.byte	0x1e	# DW_OP_mul
+	.byte	0x9f	# DW_OP_stack_value
+	.quad	.LVL9-1-.Ltext0+6	# Location list begin address (*.LLST6)
 	.quad	.LFE0-.Ltext0	# Location list end address (*.LLST6)
 	.value	0x5	# Location expression size
 	.byte	0x7d	# DW_OP_breg13


At least I hope the same case can happen in some real world case I cannot
reproduce now without such artifical .s patching.


Thanks,
Jan