* Problem with location lists and variables on stack
@ 2003-10-01 14:43 Josef Zlomek
2003-10-01 14:49 ` Daniel Jacobowitz
0 siblings, 1 reply; 16+ messages in thread
From: Josef Zlomek @ 2003-10-01 14:43 UTC (permalink / raw)
To: gdb
[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]
Hello,
I writing a better pass (variable tracking) for GCC which finally emits
location lists for variables. (If you are insterested it is at
http://artax.karlin.mff.cuni.cz/~zlomj9am/download/vt-main.patch
It still contains many debugging checks and (disabled) prints.)
Let the local variables and (some) arguments be addressed using stack pointer,
for example x86-64 architecture with variables addressed using %rsp.
The address emitted for variables located on stack by my new patch is always
DW_OP_fbreg + constant.
When I was testing the emitted debug info with mainline GDB I found that
GDB probably does not adjust addresses of variables when stack pointer changes
(like because of "pushq" instruction) if using location lists.
I think GDB should adjust the address of %rsp addressed variables according to
change of %rsp (probably DWARF2 sais so for DW_OP_fbreg). I think it is a
better solution than emitting new locations to location list for all variables
located on stack after each "push" and "pop" which would cause too large debug
info.
When I looked to gdb/dwarf2loc.c I see there:
/* FIXME: cagney/2003-03-26: This code should be using
get_frame_base_address(), and then implement a dwarf2 specific
this_base method. */
Probably this is related to my problem.
I tested it on attached C file, assembler with debug info and x86-64 binary
is attached too.
GDB's output:
# g is the first argument on stack, the first 6 arguments are in registers
Breakpoint 1, func1 (a=10, b=20, c=30, d=40, e=50, f=60, g=70, seq=0) at m.c:5
5 {
2: x/i $pc 0x400400 <func1>: push %r12
1: g = 70
(gdb) ni
0x0000000000400402 5 {
2: x/i $pc 0x400402 <func1+2>: mov %rcx,%r12
# here it looks GDB did not recompute address
1: g = 4195497
(gdb)
0x0000000000400405 5 {
2: x/i $pc 0x400405 <func1+5>: mov %r8,%rcx
1: g = 4195497
(gdb)
0x0000000000400408 5 {
2: x/i $pc 0x400408 <func1+8>: mov %rdx,%r10
1: g = 4195497
(gdb)
0x000000000040040b 5 {
2: x/i $pc 0x40040b <func1+11>: push %rbp
1: g = 4195497
(gdb)
0x000000000040040c 5 {
2: x/i $pc 0x40040c <func1+12>: mov %rdi,%rbp
1: g = 4195520
(gdb)
0x000000000040040f 5 {
2: x/i $pc 0x40040f <func1+15>: push %rbx
1: g = 4195520
(gdb)
0x0000000000400410 5 {
2: x/i $pc 0x400410 <func1+16>: mov 0x20(%rsp,1),%r8
1: g = 548682067112
# here g was loaded from stack to %r8
(gdb)
0x0000000000400415 5 {
2: x/i $pc 0x400415 <func1+21>: mov %rsi,%rbx
1: g = 70
(gdb)
Josef
[-- Attachment #2: m.c --]
[-- Type: text/x-csrc, Size: 296 bytes --]
long volatile vol;
long
func1 (long a, long b, long c, long d, long e, long f, long g, int seq)
{
vol = a + b + c + d + e + f + g;
if (seq == 3)
return vol;
return func1 (g, f, e, d, c, b, a, seq + 1);
}
int
main ()
{
vol = func1 (10, 20, 30, 40, 50, 60, 70, 0);
return (int) vol;
}
[-- Attachment #3: m.s --]
[-- Type: text/plain, Size: 18353 bytes --]
.file "m.c"
.section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
.section .debug_info,"",@progbits
.Ldebug_info0:
.section .debug_line,"",@progbits
.Ldebug_line0:
.text
.Ltext0:
.p2align 4,,15
.globl func1
.type func1, @function
func1:
.LFB2:
# m.c:5
.file 1 "m.c"
.loc 1 5 0
.LVL0:
# basic block 0
pushq %r12
.LCFI0:
movq %rcx, %r12
.LVL1:
movq %r8, %rcx
.LVL2:
movq %rdx, %r10
.LVL3:
pushq %rbp
.LCFI1:
movq %rdi, %rbp
.LVL4:
pushq %rbx
.LCFI2:
movq 32(%rsp), %r8
.LVL5:
movq %rsi, %rbx
.LVL6:
movl 40(%rsp), %r11d
.LVL7:
jmp .L3
.p2align 4,,7
.L6:
# basic block 1
# m.c:11
.loc 1 11 0
movq %r10, %rdx
.LVL8:
movq %rbx, %rsi
.LVL9:
movq %rbp, %rdi
.LVL10:
movq %r9, %rbx
.LVL11:
movq %r8, %rbp
.LVL12:
movq %rcx, %r10
.LVL13:
movq %rsi, %r9
.LVL14:
movq %rdx, %rcx
.LVL15:
movq %rdi, %r8
incl %r11d
.L3:
# basic block 2
# m.c:6
.loc 1 6 0
leaq (%rbp,%rbx), %rax
addq %r10, %rax
addq %r12, %rax
addq %rcx, %rax
addq %r9, %rax
addq %r8, %rax
# m.c:8
.loc 1 8 0
cmpl $3, %r11d
# m.c:6
.loc 1 6 0
movq %rax, vol(%rip)
# m.c:8
.loc 1 8 0
jne .L6
# basic block 3
# m.c:12
.loc 1 12 0
popq %rbx
.LVL16:
popq %rbp
.LVL17:
popq %r12
.LVL18:
# m.c:9
.loc 1 9 0
movq vol(%rip), %rax
# m.c:12
.loc 1 12 0
ret
.LFE2:
.size func1, .-func1
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB3:
# m.c:16
.loc 1 16 0
# basic block 0
subq $16, %rsp
.LCFI3:
# m.c:17
.loc 1 17 0
movl $60, %r9d
movl $50, %r8d
movl $40, %ecx
movl $30, %edx
movl $20, %esi
movl $10, %edi
movl $0, 8(%rsp)
movq $70, (%rsp)
call func1
movq %rax, vol(%rip)
# m.c:18
.loc 1 18 0
movq vol(%rip), %rax
# m.c:19
.loc 1 19 0
addq $16, %rsp
ret
.LFE3:
.size main, .-main
.comm vol,8,8
#APP
.section .debug_frame,"",@progbits
.Lframe0:
.long .LECIE0-.LSCIE0 # Length of Common Information Entry
.LSCIE0:
.long 0xffffffff # CIE Identifier Tag
.byte 0x1 # CIE Version
.ascii "\0" # CIE Augmentation
.uleb128 0x1 # CIE Code Alignment Factor
.sleb128 -8 # CIE Data Alignment Factor
.byte 0x10 # CIE RA Column
.byte 0xc # DW_CFA_def_cfa
.uleb128 0x7
.uleb128 0x8
.byte 0x90 # DW_CFA_offset, column 0x10
.uleb128 0x1
.align 8
.LECIE0:
.LSFDE0:
.long .LEFDE0-.LASFDE0 # FDE Length
.LASFDE0:
.long .Lframe0 # FDE CIE offset
.quad .LFB2 # FDE initial location
.quad .LFE2-.LFB2 # FDE address range
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI0-.LFB2
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x10
.byte 0x8c # DW_CFA_offset, column 0xc
.uleb128 0x2
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI1-.LCFI0
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x18
.byte 0x86 # DW_CFA_offset, column 0x6
.uleb128 0x3
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI2-.LCFI1
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x20
.byte 0x83 # DW_CFA_offset, column 0x3
.uleb128 0x4
.align 8
.LEFDE0:
.LSFDE2:
.long .LEFDE2-.LASFDE2 # FDE Length
.LASFDE2:
.long .Lframe0 # FDE CIE offset
.quad .LFB3 # FDE initial location
.quad .LFE3-.LFB3 # FDE address range
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI3-.LFB3
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x18
.align 8
.LEFDE2:
#NO_APP
#APP
.section .eh_frame,"a",@progbits
.Lframe1:
.long .LECIE1-.LSCIE1 # Length of Common Information Entry
.LSCIE1:
.long 0x0 # CIE Identifier Tag
.byte 0x1 # CIE Version
.ascii "\0" # CIE Augmentation
.uleb128 0x1 # CIE Code Alignment Factor
.sleb128 -8 # CIE Data Alignment Factor
.byte 0x10 # CIE RA Column
.byte 0xc # DW_CFA_def_cfa
.uleb128 0x7
.uleb128 0x8
.byte 0x90 # DW_CFA_offset, column 0x10
.uleb128 0x1
.align 8
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1 # FDE Length
.LASFDE1:
.long .LASFDE1-.Lframe1 # FDE CIE offset
.quad .LFB2 # FDE initial location
.quad .LFE2-.LFB2 # FDE address range
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI0-.LFB2
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x10
.byte 0x8c # DW_CFA_offset, column 0xc
.uleb128 0x2
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI1-.LCFI0
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x18
.byte 0x86 # DW_CFA_offset, column 0x6
.uleb128 0x3
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI2-.LCFI1
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x20
.byte 0x83 # DW_CFA_offset, column 0x3
.uleb128 0x4
.align 8
.LEFDE1:
.LSFDE3:
.long .LEFDE3-.LASFDE3 # FDE Length
.LASFDE3:
.long .LASFDE3-.Lframe1 # FDE CIE offset
.quad .LFB3 # FDE initial location
.quad .LFE3-.LFB3 # FDE address range
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI3-.LFB3
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x18
.align 8
.LEFDE3:
#NO_APP
.text
.Letext0:
.section .debug_loc,"",@progbits
.Ldebug_loc0:
.LLST0:
.quad .LVL0-.text # Location list begin address (*.LLST0)
.quad .LVL4-.text # Location list end address (*.LLST0)
.value 0x1 # Location expression size
.byte 0x55 # DW_OP_reg5
.quad .LVL4-.text # Location list begin address (*.LLST0)
.quad .LVL10-.text # Location list end address (*.LLST0)
.value 0x1 # Location expression size
.byte 0x56 # DW_OP_reg6
.quad .LVL10-.text # Location list begin address (*.LLST0)
.quad .LVL12-.text # Location list end address (*.LLST0)
.value 0x1 # Location expression size
.byte 0x55 # DW_OP_reg5
.quad .LVL12-.text # Location list begin address (*.LLST0)
.quad .LVL15-.text # Location list end address (*.LLST0)
.value 0x1 # Location expression size
.byte 0x56 # DW_OP_reg6
.quad .LVL15-.text # Location list begin address (*.LLST0)
.quad .LFE2-.text # Location list end address (*.LLST0)
.value 0x1 # Location expression size
.byte 0x55 # DW_OP_reg5
.quad 0x0 # Location list terminator begin (*.LLST0)
.quad 0x0 # Location list terminator end (*.LLST0)
.LLST1:
.quad .LVL0-.text # Location list begin address (*.LLST1)
.quad .LVL6-.text # Location list end address (*.LLST1)
.value 0x1 # Location expression size
.byte 0x54 # DW_OP_reg4
.quad .LVL6-.text # Location list begin address (*.LLST1)
.quad .LVL9-.text # Location list end address (*.LLST1)
.value 0x1 # Location expression size
.byte 0x53 # DW_OP_reg3
.quad .LVL9-.text # Location list begin address (*.LLST1)
.quad .LVL11-.text # Location list end address (*.LLST1)
.value 0x1 # Location expression size
.byte 0x54 # DW_OP_reg4
.quad .LVL11-.text # Location list begin address (*.LLST1)
.quad .LVL13-.text # Location list end address (*.LLST1)
.value 0x1 # Location expression size
.byte 0x53 # DW_OP_reg3
.quad .LVL13-.text # Location list begin address (*.LLST1)
.quad .LFE2-.text # Location list end address (*.LLST1)
.value 0x1 # Location expression size
.byte 0x54 # DW_OP_reg4
.quad 0x0 # Location list terminator begin (*.LLST1)
.quad 0x0 # Location list terminator end (*.LLST1)
.LLST2:
.quad .LVL0-.text # Location list begin address (*.LLST2)
.quad .LVL3-.text # Location list end address (*.LLST2)
.value 0x1 # Location expression size
.byte 0x51 # DW_OP_reg1
.quad .LVL3-.text # Location list begin address (*.LLST2)
.quad .LVL8-.text # Location list end address (*.LLST2)
.value 0x1 # Location expression size
.byte 0x5a # DW_OP_reg10
.quad .LVL8-.text # Location list begin address (*.LLST2)
.quad .LVL13-.text # Location list end address (*.LLST2)
.value 0x1 # Location expression size
.byte 0x51 # DW_OP_reg1
.quad .LVL13-.text # Location list begin address (*.LLST2)
.quad .LVL14-.text # Location list end address (*.LLST2)
.value 0x1 # Location expression size
.byte 0x5a # DW_OP_reg10
.quad .LVL14-.text # Location list begin address (*.LLST2)
.quad .LFE2-.text # Location list end address (*.LLST2)
.value 0x1 # Location expression size
.byte 0x51 # DW_OP_reg1
.quad 0x0 # Location list terminator begin (*.LLST2)
.quad 0x0 # Location list terminator end (*.LLST2)
.LLST3:
.quad .LVL0-.text # Location list begin address (*.LLST3)
.quad .LVL1-.text # Location list end address (*.LLST3)
.value 0x1 # Location expression size
.byte 0x52 # DW_OP_reg2
.quad .LVL1-.text # Location list begin address (*.LLST3)
.quad .LVL18-.text # Location list end address (*.LLST3)
.value 0x1 # Location expression size
.byte 0x5c # DW_OP_reg12
.quad 0x0 # Location list terminator begin (*.LLST3)
.quad 0x0 # Location list terminator end (*.LLST3)
.LLST4:
.quad .LVL0-.text # Location list begin address (*.LLST4)
.quad .LVL2-.text # Location list end address (*.LLST4)
.value 0x1 # Location expression size
.byte 0x58 # DW_OP_reg8
.quad .LVL2-.text # Location list begin address (*.LLST4)
.quad .LFE2-.text # Location list end address (*.LLST4)
.value 0x1 # Location expression size
.byte 0x52 # DW_OP_reg2
.quad 0x0 # Location list terminator begin (*.LLST4)
.quad 0x0 # Location list terminator end (*.LLST4)
.LLST5:
.quad .LVL0-.text # Location list begin address (*.LLST5)
.quad .LVL5-.text # Location list end address (*.LLST5)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 8
.quad .LVL5-.text # Location list begin address (*.LLST5)
.quad .LFE2-.text # Location list end address (*.LLST5)
.value 0x1 # Location expression size
.byte 0x58 # DW_OP_reg8
.quad 0x0 # Location list terminator begin (*.LLST5)
.quad 0x0 # Location list terminator end (*.LLST5)
.LLST6:
.quad .LVL0-.text # Location list begin address (*.LLST6)
.quad .LVL7-.text # Location list end address (*.LLST6)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 16
.quad .LVL7-.text # Location list begin address (*.LLST6)
.quad .LFE2-.text # Location list end address (*.LLST6)
.value 0x1 # Location expression size
.byte 0x5b # DW_OP_reg11
.quad 0x0 # Location list terminator begin (*.LLST6)
.quad 0x0 # Location list terminator end (*.LLST6)
.section .debug_info
.long 0xfd # Length of Compilation Unit Info
.value 0x2 # DWARF version number
.long .Ldebug_abbrev0 # Offset Into Abbrev. Section
.byte 0x8 # Pointer Size (in bytes)
.uleb128 0x1 # (DIE (0xb) DW_TAG_compile_unit)
.long .Ldebug_line0 # DW_AT_stmt_list
.quad .Letext0 # DW_AT_high_pc
.quad .Ltext0 # DW_AT_low_pc
.long .LASF1 # DW_AT_producer: "GNU C 3.4 20030924 (experimental)"
.byte 0x1 # DW_AT_language
.ascii "m.c\0" # DW_AT_name
.long .LASF2 # DW_AT_comp_dir: "/abuild2/zlomekj/vt"
.uleb128 0x2 # (DIE (0x2d) DW_TAG_subprogram)
.long 0xb9 # DW_AT_sibling
.byte 0x1 # DW_AT_external
.long .LASF3 # DW_AT_name: "func1"
.byte 0x1 # DW_AT_decl_file
.byte 0x5 # DW_AT_decl_line
.byte 0x1 # DW_AT_prototyped
.long 0xb9 # DW_AT_type
.quad .LFB2 # DW_AT_low_pc
.quad .LFE2 # DW_AT_high_pc
.byte 0x1 # DW_AT_frame_base
.byte 0x57 # DW_OP_reg7
.uleb128 0x3 # (DIE (0x50) DW_TAG_formal_parameter)
.ascii "a\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xb9 # DW_AT_type
.long .LLST0 # DW_AT_location
.uleb128 0x3 # (DIE (0x5d) DW_TAG_formal_parameter)
.ascii "b\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xb9 # DW_AT_type
.long .LLST1 # DW_AT_location
.uleb128 0x3 # (DIE (0x6a) DW_TAG_formal_parameter)
.ascii "c\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xb9 # DW_AT_type
.long .LLST2 # DW_AT_location
.uleb128 0x3 # (DIE (0x77) DW_TAG_formal_parameter)
.ascii "d\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xb9 # DW_AT_type
.long .LLST3 # DW_AT_location
.uleb128 0x3 # (DIE (0x84) DW_TAG_formal_parameter)
.ascii "e\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xb9 # DW_AT_type
.long .LLST4 # DW_AT_location
.uleb128 0x4 # (DIE (0x91) DW_TAG_formal_parameter)
.ascii "f\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xb9 # DW_AT_type
.byte 0x1 # DW_AT_location
.byte 0x59 # DW_OP_reg9
.uleb128 0x3 # (DIE (0x9c) DW_TAG_formal_parameter)
.ascii "g\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xb9 # DW_AT_type
.long .LLST5 # DW_AT_location
.uleb128 0x3 # (DIE (0xa9) DW_TAG_formal_parameter)
.ascii "seq\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xc0 # DW_AT_type
.long .LLST6 # DW_AT_location
.byte 0x0 # end of children of DIE 0x2d
.uleb128 0x5 # (DIE (0xb9) DW_TAG_base_type)
.long .LASF0 # DW_AT_name: "long int"
.byte 0x8 # DW_AT_byte_size
.byte 0x5 # DW_AT_encoding
.uleb128 0x6 # (DIE (0xc0) DW_TAG_base_type)
.ascii "int\0" # DW_AT_name
.byte 0x4 # DW_AT_byte_size
.byte 0x5 # DW_AT_encoding
.uleb128 0x7 # (DIE (0xc7) DW_TAG_subprogram)
.byte 0x1 # DW_AT_external
.long .LASF4 # DW_AT_name: "main"
.byte 0x1 # DW_AT_decl_file
.byte 0x10 # DW_AT_decl_line
.long 0xc0 # DW_AT_type
.quad .LFB3 # DW_AT_low_pc
.quad .LFE3 # DW_AT_high_pc
.byte 0x1 # DW_AT_frame_base
.byte 0x57 # DW_OP_reg7
.uleb128 0x8 # (DIE (0xe5) DW_TAG_variable)
.ascii "vol\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x1 # DW_AT_decl_line
.long 0xfb # DW_AT_type
.byte 0x1 # DW_AT_external
.byte 0x9 # DW_AT_location
.byte 0x3 # DW_OP_addr
.quad vol
.uleb128 0x9 # (DIE (0xfb) DW_TAG_volatile_type)
.long 0xb9 # DW_AT_type
.byte 0x0 # end of children of DIE 0xb
.section .debug_abbrev
.uleb128 0x1 # (abbrev code)
.uleb128 0x11 # (TAG: DW_TAG_compile_unit)
.byte 0x1 # DW_children_yes
.uleb128 0x10 # (DW_AT_stmt_list)
.uleb128 0x6 # (DW_FORM_data4)
.uleb128 0x12 # (DW_AT_high_pc)
.uleb128 0x1 # (DW_FORM_addr)
.uleb128 0x11 # (DW_AT_low_pc)
.uleb128 0x1 # (DW_FORM_addr)
.uleb128 0x25 # (DW_AT_producer)
.uleb128 0xe # (DW_FORM_strp)
.uleb128 0x13 # (DW_AT_language)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3 # (DW_AT_name)
.uleb128 0x8 # (DW_FORM_string)
.uleb128 0x1b # (DW_AT_comp_dir)
.uleb128 0xe # (DW_FORM_strp)
.byte 0x0
.byte 0x0
.uleb128 0x2 # (abbrev code)
.uleb128 0x2e # (TAG: DW_TAG_subprogram)
.byte 0x1 # DW_children_yes
.uleb128 0x1 # (DW_AT_sibling)
.uleb128 0x13 # (DW_FORM_ref4)
.uleb128 0x3f # (DW_AT_external)
.uleb128 0xc # (DW_FORM_flag)
.uleb128 0x3 # (DW_AT_name)
.uleb128 0xe # (DW_FORM_strp)
.uleb128 0x3a # (DW_AT_decl_file)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3b # (DW_AT_decl_line)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x27 # (DW_AT_prototyped)
.uleb128 0xc # (DW_FORM_flag)
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
.uleb128 0x11 # (DW_AT_low_pc)
.uleb128 0x1 # (DW_FORM_addr)
.uleb128 0x12 # (DW_AT_high_pc)
.uleb128 0x1 # (DW_FORM_addr)
.uleb128 0x40 # (DW_AT_frame_base)
.uleb128 0xa # (DW_FORM_block1)
.byte 0x0
.byte 0x0
.uleb128 0x3 # (abbrev code)
.uleb128 0x5 # (TAG: DW_TAG_formal_parameter)
.byte 0x0 # DW_children_no
.uleb128 0x3 # (DW_AT_name)
.uleb128 0x8 # (DW_FORM_string)
.uleb128 0x3a # (DW_AT_decl_file)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3b # (DW_AT_decl_line)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
.uleb128 0x2 # (DW_AT_location)
.uleb128 0x6 # (DW_FORM_data4)
.byte 0x0
.byte 0x0
.uleb128 0x4 # (abbrev code)
.uleb128 0x5 # (TAG: DW_TAG_formal_parameter)
.byte 0x0 # DW_children_no
.uleb128 0x3 # (DW_AT_name)
.uleb128 0x8 # (DW_FORM_string)
.uleb128 0x3a # (DW_AT_decl_file)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3b # (DW_AT_decl_line)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
.uleb128 0x2 # (DW_AT_location)
.uleb128 0xa # (DW_FORM_block1)
.byte 0x0
.byte 0x0
.uleb128 0x5 # (abbrev code)
.uleb128 0x24 # (TAG: DW_TAG_base_type)
.byte 0x0 # DW_children_no
.uleb128 0x3 # (DW_AT_name)
.uleb128 0xe # (DW_FORM_strp)
.uleb128 0xb # (DW_AT_byte_size)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3e # (DW_AT_encoding)
.uleb128 0xb # (DW_FORM_data1)
.byte 0x0
.byte 0x0
.uleb128 0x6 # (abbrev code)
.uleb128 0x24 # (TAG: DW_TAG_base_type)
.byte 0x0 # DW_children_no
.uleb128 0x3 # (DW_AT_name)
.uleb128 0x8 # (DW_FORM_string)
.uleb128 0xb # (DW_AT_byte_size)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3e # (DW_AT_encoding)
.uleb128 0xb # (DW_FORM_data1)
.byte 0x0
.byte 0x0
.uleb128 0x7 # (abbrev code)
.uleb128 0x2e # (TAG: DW_TAG_subprogram)
.byte 0x0 # DW_children_no
.uleb128 0x3f # (DW_AT_external)
.uleb128 0xc # (DW_FORM_flag)
.uleb128 0x3 # (DW_AT_name)
.uleb128 0xe # (DW_FORM_strp)
.uleb128 0x3a # (DW_AT_decl_file)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3b # (DW_AT_decl_line)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
.uleb128 0x11 # (DW_AT_low_pc)
.uleb128 0x1 # (DW_FORM_addr)
.uleb128 0x12 # (DW_AT_high_pc)
.uleb128 0x1 # (DW_FORM_addr)
.uleb128 0x40 # (DW_AT_frame_base)
.uleb128 0xa # (DW_FORM_block1)
.byte 0x0
.byte 0x0
.uleb128 0x8 # (abbrev code)
.uleb128 0x34 # (TAG: DW_TAG_variable)
.byte 0x0 # DW_children_no
.uleb128 0x3 # (DW_AT_name)
.uleb128 0x8 # (DW_FORM_string)
.uleb128 0x3a # (DW_AT_decl_file)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3b # (DW_AT_decl_line)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
.uleb128 0x3f # (DW_AT_external)
.uleb128 0xc # (DW_FORM_flag)
.uleb128 0x2 # (DW_AT_location)
.uleb128 0xa # (DW_FORM_block1)
.byte 0x0
.byte 0x0
.uleb128 0x9 # (abbrev code)
.uleb128 0x35 # (TAG: DW_TAG_volatile_type)
.byte 0x0 # DW_children_no
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
.byte 0x0
.byte 0x0
.byte 0x0
.section .debug_pubnames,"",@progbits
.long 0x29 # Length of Public Names Info
.value 0x2 # DWARF Version
.long .Ldebug_info0 # Offset of Compilation Unit Info
.long 0x101 # Compilation Unit Length
.long 0x2d # DIE offset
.ascii "func1\0" # external name
.long 0xc7 # DIE offset
.ascii "main\0" # external name
.long 0xe5 # DIE offset
.ascii "vol\0" # external name
.long 0x0
.section .debug_aranges,"",@progbits
.long 0x2c # Length of Address Ranges Info
.value 0x2 # DWARF Version
.long .Ldebug_info0 # Offset of Compilation Unit Info
.byte 0x8 # Size of Address
.byte 0x0 # Size of Segment Descriptor
.value 0x0 # Pad to 16 byte boundary
.value 0x0
.quad .Ltext0 # Address
.quad .Letext0-.Ltext0 # Length
.quad 0x0
.quad 0x0
.section .debug_str,"MS",@progbits,1
.LASF4:
.string "main"
.LASF3:
.string "func1"
.LASF1:
.string "GNU C 3.4 20030924 (experimental)"
.LASF2:
.string "/abuild2/zlomekj/vt"
.LASF0:
.string "long int"
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4 20030924 (experimental)"
[-- Attachment #4: a.out --]
[-- Type: application/octet-stream, Size: 15033 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-01 14:43 Problem with location lists and variables on stack Josef Zlomek
@ 2003-10-01 14:49 ` Daniel Jacobowitz
2003-10-01 15:21 ` Josef Zlomek
2003-10-01 15:44 ` Josef Zlomek
0 siblings, 2 replies; 16+ messages in thread
From: Daniel Jacobowitz @ 2003-10-01 14:49 UTC (permalink / raw)
To: Josef Zlomek; +Cc: gdb
On Wed, Oct 01, 2003 at 04:43:30PM +0200, Josef Zlomek wrote:
> Hello,
>
> I writing a better pass (variable tracking) for GCC which finally emits
> location lists for variables. (If you are insterested it is at
> http://artax.karlin.mff.cuni.cz/~zlomj9am/download/vt-main.patch
> It still contains many debugging checks and (disabled) prints.)
>
> Let the local variables and (some) arguments be addressed using stack pointer,
> for example x86-64 architecture with variables addressed using %rsp.
> The address emitted for variables located on stack by my new patch is always
> DW_OP_fbreg + constant.
>
> When I was testing the emitted debug info with mainline GDB I found that
> GDB probably does not adjust addresses of variables when stack pointer changes
> (like because of "pushq" instruction) if using location lists.
> I think GDB should adjust the address of %rsp addressed variables according to
> change of %rsp (probably DWARF2 sais so for DW_OP_fbreg). I think it is a
> better solution than emitting new locations to location list for all variables
> located on stack after each "push" and "pop" which would cause too large debug
> info.
>
> When I looked to gdb/dwarf2loc.c I see there:
> /* FIXME: cagney/2003-03-26: This code should be using
> get_frame_base_address(), and then implement a dwarf2 specific
> this_base method. */
> Probably this is related to my problem.
The FIXME is a cleanliness problem. We do evaluate DW_AT_frame_base,
so it _ought_ to work.
> I tested it on attached C file, assembler with debug info and x86-64 binary
> is attached too.
Do you suppose you could produce an x86 (ia32) testcase? I don't have
x86-64 hardware available yet. The debug info looks right so I'd like
to get my fingers into the problem.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-01 14:49 ` Daniel Jacobowitz
@ 2003-10-01 15:21 ` Josef Zlomek
2003-10-01 15:44 ` Josef Zlomek
1 sibling, 0 replies; 16+ messages in thread
From: Josef Zlomek @ 2003-10-01 15:21 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
> > I writing a better pass (variable tracking) for GCC which finally emits
> > location lists for variables. (If you are insterested it is at
> > http://artax.karlin.mff.cuni.cz/~zlomj9am/download/vt-main.patch
> > It still contains many debugging checks and (disabled) prints.)
> >
> > Let the local variables and (some) arguments be addressed using stack pointer,
> > for example x86-64 architecture with variables addressed using %rsp.
> > The address emitted for variables located on stack by my new patch is always
> > DW_OP_fbreg + constant.
> >
> > When I was testing the emitted debug info with mainline GDB I found that
> > GDB probably does not adjust addresses of variables when stack pointer changes
> > (like because of "pushq" instruction) if using location lists.
> > I think GDB should adjust the address of %rsp addressed variables according to
> > change of %rsp (probably DWARF2 sais so for DW_OP_fbreg). I think it is a
> > better solution than emitting new locations to location list for all variables
> > located on stack after each "push" and "pop" which would cause too large debug
> > info.
> >
> > When I looked to gdb/dwarf2loc.c I see there:
> > /* FIXME: cagney/2003-03-26: This code should be using
> > get_frame_base_address(), and then implement a dwarf2 specific
> > this_base method. */
> > Probably this is related to my problem.
>
> The FIXME is a cleanliness problem. We do evaluate DW_AT_frame_base,
> so it _ought_ to work.
>
> > I tested it on attached C file, assembler with debug info and x86-64 binary
> > is attached too.
>
> Do you suppose you could produce an x86 (ia32) testcase? I don't have
> x86-64 hardware available yet. The debug info looks right so I'd like
> to get my fingers into the problem.
I think it will be the same on i386 with -fomit-frame-pointer.
I'll test it and send you files if needed.
Josef
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-01 14:49 ` Daniel Jacobowitz
2003-10-01 15:21 ` Josef Zlomek
@ 2003-10-01 15:44 ` Josef Zlomek
2003-10-01 15:54 ` Daniel Jacobowitz
1 sibling, 1 reply; 16+ messages in thread
From: Josef Zlomek @ 2003-10-01 15:44 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]
> > Let the local variables and (some) arguments be addressed using stack pointer,
> > for example x86-64 architecture with variables addressed using %rsp.
> > The address emitted for variables located on stack by my new patch is always
> > DW_OP_fbreg + constant.
> >
> > When I was testing the emitted debug info with mainline GDB I found that
> > GDB probably does not adjust addresses of variables when stack pointer changes
> > (like because of "pushq" instruction) if using location lists.
> > I think GDB should adjust the address of %rsp addressed variables according to
> > change of %rsp (probably DWARF2 sais so for DW_OP_fbreg). I think it is a
> > better solution than emitting new locations to location list for all variables
> > located on stack after each "push" and "pop" which would cause too large debug
> > info.
> >
> > When I looked to gdb/dwarf2loc.c I see there:
> > /* FIXME: cagney/2003-03-26: This code should be using
> > get_frame_base_address(), and then implement a dwarf2 specific
> > this_base method. */
> > Probably this is related to my problem.
>
> The FIXME is a cleanliness problem. We do evaluate DW_AT_frame_base,
> so it _ought_ to work.
>
> > I tested it on attached C file, assembler with debug info and x86-64 binary
> > is attached too.
>
> Do you suppose you could produce an x86 (ia32) testcase? I don't have
> x86-64 hardware available yet. The debug info looks right so I'd like
> to get my fingers into the problem.
Here is the x86 assembler.
Josef
[-- Attachment #2: m-i386.s --]
[-- Type: text/plain, Size: 18812 bytes --]
.file "m.c"
.section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
.section .debug_info,"",@progbits
.Ldebug_info0:
.section .debug_line,"",@progbits
.Ldebug_line0:
.text
.Ltext0:
.p2align 4,,15
.globl func1
.type func1, @function
func1:
.LFB2:
# m.c:5
.file 1 "m.c"
.loc 1 5 0
.LVL0:
# basic block 0
pushl %ebp
.LCFI0:
pushl %edi
.LCFI1:
pushl %esi
.LCFI2:
pushl %ebx
.LCFI3:
subl $16, %esp
.LCFI4:
movl 36(%esp), %eax
movl 44(%esp), %edi
.LVL1:
movl 56(%esp), %esi
.LVL2:
movl 60(%esp), %ebx
.LVL3:
movl %eax, 12(%esp)
movl 40(%esp), %eax
movl 64(%esp), %ebp
.LVL4:
movl %eax, 8(%esp)
movl 48(%esp), %eax
.LVL5:
movl %eax, 4(%esp)
movl 52(%esp), %eax
.LVL6:
movl %eax, (%esp)
jmp .L3
.p2align 4,,7
.L6:
# basic block 1
# m.c:11
.loc 1 11 0
movl 8(%esp), %edx
.LVL7:
movl %edi, %eax
.LVL8:
movl %esi, 8(%esp)
movl 12(%esp), %ecx
.LVL9:
incl %ebp
.LVL10:
movl %ebx, 12(%esp)
movl (%esp), %edi
.LVL11:
movl %edx, %esi
.LVL12:
movl %eax, (%esp)
.LVL13:
movl %ecx, %ebx
.L3:
# basic block 2
# m.c:6
.loc 1 6 0
movl 8(%esp), %edx
movl 12(%esp), %eax
movl 4(%esp), %ecx
addl %edx, %eax
movl (%esp), %edx
addl %edi, %eax
addl %ecx, %eax
addl %edx, %eax
addl %esi, %eax
addl %ebx, %eax
# m.c:8
.loc 1 8 0
cmpl $3, %ebp
# m.c:6
.loc 1 6 0
movl %eax, vol
# m.c:8
.loc 1 8 0
jne .L6
# basic block 3
# m.c:9
.loc 1 9 0
movl vol, %eax
# m.c:12
.loc 1 12 0
addl $16, %esp
popl %ebx
.LVL14:
popl %esi
.LVL15:
popl %edi
.LVL16:
popl %ebp
.LVL17:
ret
.LFE2:
.size func1, .-func1
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB3:
# m.c:16
.loc 1 16 0
# basic block 0
pushl %ebp
.LCFI5:
# m.c:17
.loc 1 17 0
xorl %eax, %eax
# m.c:16
.loc 1 16 0
movl %esp, %ebp
.LCFI6:
subl $40, %esp
.LCFI7:
# m.c:17
.loc 1 17 0
movl $20, %ecx
# m.c:16
.loc 1 16 0
andl $-16, %esp
# m.c:17
.loc 1 17 0
movl %eax, 28(%esp)
movl $70, %eax
movl %eax, 24(%esp)
movl $60, %eax
movl %eax, 20(%esp)
movl $50, %eax
movl %eax, 16(%esp)
movl $40, %eax
movl %eax, 12(%esp)
movl $30, %eax
movl %eax, 8(%esp)
movl %ecx, 4(%esp)
movl $10, (%esp)
call func1
movl %eax, vol
# m.c:18
.loc 1 18 0
movl vol, %eax
# m.c:19
.loc 1 19 0
leave
ret
.LFE3:
.size main, .-main
.comm vol,4,4
#APP
.section .debug_frame,"",@progbits
.Lframe0:
.long .LECIE0-.LSCIE0 # Length of Common Information Entry
.LSCIE0:
.long 0xffffffff # CIE Identifier Tag
.byte 0x1 # CIE Version
.ascii "\0" # CIE Augmentation
.uleb128 0x1 # CIE Code Alignment Factor
.sleb128 -4 # CIE Data Alignment Factor
.byte 0x8 # CIE RA Column
.byte 0xc # DW_CFA_def_cfa
.uleb128 0x4
.uleb128 0x4
.byte 0x88 # DW_CFA_offset, column 0x8
.uleb128 0x1
.align 4
.LECIE0:
.LSFDE0:
.long .LEFDE0-.LASFDE0 # FDE Length
.LASFDE0:
.long .Lframe0 # FDE CIE offset
.long .LFB2 # FDE initial location
.long .LFE2-.LFB2 # FDE address range
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI0-.LFB2
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x8
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI1-.LCFI0
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0xc
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI2-.LCFI1
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x10
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI3-.LCFI2
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x14
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI4-.LCFI3
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x24
.byte 0x83 # DW_CFA_offset, column 0x3
.uleb128 0x5
.byte 0x86 # DW_CFA_offset, column 0x6
.uleb128 0x4
.byte 0x87 # DW_CFA_offset, column 0x7
.uleb128 0x3
.byte 0x85 # DW_CFA_offset, column 0x5
.uleb128 0x2
.align 4
.LEFDE0:
.LSFDE2:
.long .LEFDE2-.LASFDE2 # FDE Length
.LASFDE2:
.long .Lframe0 # FDE CIE offset
.long .LFB3 # FDE initial location
.long .LFE3-.LFB3 # FDE address range
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI5-.LFB3
.byte 0xe # DW_CFA_def_cfa_offset
.uleb128 0x8
.byte 0x85 # DW_CFA_offset, column 0x5
.uleb128 0x2
.byte 0x4 # DW_CFA_advance_loc4
.long .LCFI6-.LCFI5
.byte 0xd # DW_CFA_def_cfa_register
.uleb128 0x5
.align 4
.LEFDE2:
#NO_APP
.text
.Letext0:
.section .debug_loc,"",@progbits
.Ldebug_loc0:
.LLST0:
.long .LVL0-.text # Location list begin address (*.LLST0)
.long .LVL3-.text # Location list end address (*.LLST0)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 4
.long .LVL3-.text # Location list begin address (*.LLST0)
.long .LVL9-.text # Location list end address (*.LLST0)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 -20
.long .LVL9-.text # Location list begin address (*.LLST0)
.long .LVL10-.text # Location list end address (*.LLST0)
.value 0x1 # Location expression size
.byte 0x51 # DW_OP_reg1
.long .LVL10-.text # Location list begin address (*.LLST0)
.long .LVL13-.text # Location list end address (*.LLST0)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 -20
.long .LVL13-.text # Location list begin address (*.LLST0)
.long .LFE2-.text # Location list end address (*.LLST0)
.value 0x1 # Location expression size
.byte 0x51 # DW_OP_reg1
.long 0x0 # Location list terminator begin (*.LLST0)
.long 0x0 # Location list terminator end (*.LLST0)
.LLST1:
.long .LVL0-.text # Location list begin address (*.LLST1)
.long .LVL4-.text # Location list end address (*.LLST1)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 8
.long .LVL4-.text # Location list begin address (*.LLST1)
.long .LVL7-.text # Location list end address (*.LLST1)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 -24
.long .LVL7-.text # Location list begin address (*.LLST1)
.long .LVL8-.text # Location list end address (*.LLST1)
.value 0x1 # Location expression size
.byte 0x52 # DW_OP_reg2
.long .LVL8-.text # Location list begin address (*.LLST1)
.long .LVL11-.text # Location list end address (*.LLST1)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 -24
.long .LVL11-.text # Location list begin address (*.LLST1)
.long .LFE2-.text # Location list end address (*.LLST1)
.value 0x1 # Location expression size
.byte 0x52 # DW_OP_reg2
.long 0x0 # Location list terminator begin (*.LLST1)
.long 0x0 # Location list terminator end (*.LLST1)
.LLST2:
.long .LVL0-.text # Location list begin address (*.LLST2)
.long .LVL1-.text # Location list end address (*.LLST2)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 12
.long .LVL1-.text # Location list begin address (*.LLST2)
.long .LVL8-.text # Location list end address (*.LLST2)
.value 0x1 # Location expression size
.byte 0x57 # DW_OP_reg7
.long .LVL8-.text # Location list begin address (*.LLST2)
.long .LVL11-.text # Location list end address (*.LLST2)
.value 0x1 # Location expression size
.byte 0x50 # DW_OP_reg0
.long .LVL11-.text # Location list begin address (*.LLST2)
.long .LVL12-.text # Location list end address (*.LLST2)
.value 0x1 # Location expression size
.byte 0x57 # DW_OP_reg7
.long .LVL12-.text # Location list begin address (*.LLST2)
.long .LVL16-.text # Location list end address (*.LLST2)
.value 0x1 # Location expression size
.byte 0x50 # DW_OP_reg0
.long .LVL16-.text # Location list begin address (*.LLST2)
.long .LFE2-.text # Location list end address (*.LLST2)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 12
.long 0x0 # Location list terminator begin (*.LLST2)
.long 0x0 # Location list terminator end (*.LLST2)
.LLST3:
.long .LVL0-.text # Location list begin address (*.LLST3)
.long .LVL5-.text # Location list end address (*.LLST3)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 16
.long .LVL5-.text # Location list begin address (*.LLST3)
.long .LFE2-.text # Location list end address (*.LLST3)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 -28
.long 0x0 # Location list terminator begin (*.LLST3)
.long 0x0 # Location list terminator end (*.LLST3)
.LLST4:
.long .LVL0-.text # Location list begin address (*.LLST4)
.long .LVL6-.text # Location list end address (*.LLST4)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 20
.long .LVL6-.text # Location list begin address (*.LLST4)
.long .LFE2-.text # Location list end address (*.LLST4)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 -32
.long 0x0 # Location list terminator begin (*.LLST4)
.long 0x0 # Location list terminator end (*.LLST4)
.LLST5:
.long .LVL0-.text # Location list begin address (*.LLST5)
.long .LVL2-.text # Location list end address (*.LLST5)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 24
.long .LVL2-.text # Location list begin address (*.LLST5)
.long .LVL15-.text # Location list end address (*.LLST5)
.value 0x1 # Location expression size
.byte 0x56 # DW_OP_reg6
.long .LVL15-.text # Location list begin address (*.LLST5)
.long .LFE2-.text # Location list end address (*.LLST5)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 24
.long 0x0 # Location list terminator begin (*.LLST5)
.long 0x0 # Location list terminator end (*.LLST5)
.LLST6:
.long .LVL0-.text # Location list begin address (*.LLST6)
.long .LVL3-.text # Location list end address (*.LLST6)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 28
.long .LVL3-.text # Location list begin address (*.LLST6)
.long .LVL14-.text # Location list end address (*.LLST6)
.value 0x1 # Location expression size
.byte 0x53 # DW_OP_reg3
.long .LVL14-.text # Location list begin address (*.LLST6)
.long .LFE2-.text # Location list end address (*.LLST6)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 28
.long 0x0 # Location list terminator begin (*.LLST6)
.long 0x0 # Location list terminator end (*.LLST6)
.LLST7:
.long .LVL0-.text # Location list begin address (*.LLST7)
.long .LVL4-.text # Location list end address (*.LLST7)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 32
.long .LVL4-.text # Location list begin address (*.LLST7)
.long .LVL17-.text # Location list end address (*.LLST7)
.value 0x1 # Location expression size
.byte 0x55 # DW_OP_reg5
.long .LVL17-.text # Location list begin address (*.LLST7)
.long .LFE2-.text # Location list end address (*.LLST7)
.value 0x2 # Location expression size
.byte 0x91 # DW_OP_fbreg
.sleb128 32
.long 0x0 # Location list terminator begin (*.LLST7)
.long 0x0 # Location list terminator end (*.LLST7)
.section .debug_info
.long 0xe3 # Length of Compilation Unit Info
.value 0x2 # DWARF version number
.long .Ldebug_abbrev0 # Offset Into Abbrev. Section
.byte 0x4 # Pointer Size (in bytes)
.uleb128 0x1 # (DIE (0xb) DW_TAG_compile_unit)
.long .Ldebug_line0 # DW_AT_stmt_list
.long .Letext0 # DW_AT_high_pc
.long .Ltext0 # DW_AT_low_pc
.long .LASF1 # DW_AT_producer: "GNU C 3.4 20030924 (experimental)"
.byte 0x1 # DW_AT_language
.ascii "m.c\0" # DW_AT_name
.long .LASF2 # DW_AT_comp_dir: "/local/zlomekj"
.uleb128 0x2 # (DIE (0x25) DW_TAG_subprogram)
.long 0xab # DW_AT_sibling
.byte 0x1 # DW_AT_external
.long .LASF3 # DW_AT_name: "func1"
.byte 0x1 # DW_AT_decl_file
.byte 0x5 # DW_AT_decl_line
.byte 0x1 # DW_AT_prototyped
.long 0xab # DW_AT_type
.long .LFB2 # DW_AT_low_pc
.long .LFE2 # DW_AT_high_pc
.byte 0x1 # DW_AT_frame_base
.byte 0x54 # DW_OP_reg4
.uleb128 0x3 # (DIE (0x40) DW_TAG_formal_parameter)
.ascii "a\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xab # DW_AT_type
.long .LLST0 # DW_AT_location
.uleb128 0x3 # (DIE (0x4d) DW_TAG_formal_parameter)
.ascii "b\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xab # DW_AT_type
.long .LLST1 # DW_AT_location
.uleb128 0x3 # (DIE (0x5a) DW_TAG_formal_parameter)
.ascii "c\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xab # DW_AT_type
.long .LLST2 # DW_AT_location
.uleb128 0x3 # (DIE (0x67) DW_TAG_formal_parameter)
.ascii "d\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xab # DW_AT_type
.long .LLST3 # DW_AT_location
.uleb128 0x3 # (DIE (0x74) DW_TAG_formal_parameter)
.ascii "e\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xab # DW_AT_type
.long .LLST4 # DW_AT_location
.uleb128 0x3 # (DIE (0x81) DW_TAG_formal_parameter)
.ascii "f\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xab # DW_AT_type
.long .LLST5 # DW_AT_location
.uleb128 0x3 # (DIE (0x8e) DW_TAG_formal_parameter)
.ascii "g\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xab # DW_AT_type
.long .LLST6 # DW_AT_location
.uleb128 0x3 # (DIE (0x9b) DW_TAG_formal_parameter)
.ascii "seq\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x4 # DW_AT_decl_line
.long 0xb2 # DW_AT_type
.long .LLST7 # DW_AT_location
.byte 0x0 # end of children of DIE 0x25
.uleb128 0x4 # (DIE (0xab) DW_TAG_base_type)
.long .LASF0 # DW_AT_name: "long int"
.byte 0x4 # DW_AT_byte_size
.byte 0x5 # DW_AT_encoding
.uleb128 0x5 # (DIE (0xb2) DW_TAG_base_type)
.ascii "int\0" # DW_AT_name
.byte 0x4 # DW_AT_byte_size
.byte 0x5 # DW_AT_encoding
.uleb128 0x6 # (DIE (0xb9) DW_TAG_subprogram)
.byte 0x1 # DW_AT_external
.long .LASF4 # DW_AT_name: "main"
.byte 0x1 # DW_AT_decl_file
.byte 0x10 # DW_AT_decl_line
.long 0xb2 # DW_AT_type
.long .LFB3 # DW_AT_low_pc
.long .LFE3 # DW_AT_high_pc
.byte 0x1 # DW_AT_frame_base
.byte 0x55 # DW_OP_reg5
.uleb128 0x7 # (DIE (0xcf) DW_TAG_variable)
.ascii "vol\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x1 # DW_AT_decl_line
.long 0xe1 # DW_AT_type
.byte 0x1 # DW_AT_external
.byte 0x5 # DW_AT_location
.byte 0x3 # DW_OP_addr
.long vol
.uleb128 0x8 # (DIE (0xe1) DW_TAG_volatile_type)
.long 0xab # DW_AT_type
.byte 0x0 # end of children of DIE 0xb
.section .debug_abbrev
.uleb128 0x1 # (abbrev code)
.uleb128 0x11 # (TAG: DW_TAG_compile_unit)
.byte 0x1 # DW_children_yes
.uleb128 0x10 # (DW_AT_stmt_list)
.uleb128 0x6 # (DW_FORM_data4)
.uleb128 0x12 # (DW_AT_high_pc)
.uleb128 0x1 # (DW_FORM_addr)
.uleb128 0x11 # (DW_AT_low_pc)
.uleb128 0x1 # (DW_FORM_addr)
.uleb128 0x25 # (DW_AT_producer)
.uleb128 0xe # (DW_FORM_strp)
.uleb128 0x13 # (DW_AT_language)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3 # (DW_AT_name)
.uleb128 0x8 # (DW_FORM_string)
.uleb128 0x1b # (DW_AT_comp_dir)
.uleb128 0xe # (DW_FORM_strp)
.byte 0x0
.byte 0x0
.uleb128 0x2 # (abbrev code)
.uleb128 0x2e # (TAG: DW_TAG_subprogram)
.byte 0x1 # DW_children_yes
.uleb128 0x1 # (DW_AT_sibling)
.uleb128 0x13 # (DW_FORM_ref4)
.uleb128 0x3f # (DW_AT_external)
.uleb128 0xc # (DW_FORM_flag)
.uleb128 0x3 # (DW_AT_name)
.uleb128 0xe # (DW_FORM_strp)
.uleb128 0x3a # (DW_AT_decl_file)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3b # (DW_AT_decl_line)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x27 # (DW_AT_prototyped)
.uleb128 0xc # (DW_FORM_flag)
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
.uleb128 0x11 # (DW_AT_low_pc)
.uleb128 0x1 # (DW_FORM_addr)
.uleb128 0x12 # (DW_AT_high_pc)
.uleb128 0x1 # (DW_FORM_addr)
.uleb128 0x40 # (DW_AT_frame_base)
.uleb128 0xa # (DW_FORM_block1)
.byte 0x0
.byte 0x0
.uleb128 0x3 # (abbrev code)
.uleb128 0x5 # (TAG: DW_TAG_formal_parameter)
.byte 0x0 # DW_children_no
.uleb128 0x3 # (DW_AT_name)
.uleb128 0x8 # (DW_FORM_string)
.uleb128 0x3a # (DW_AT_decl_file)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3b # (DW_AT_decl_line)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
.uleb128 0x2 # (DW_AT_location)
.uleb128 0x6 # (DW_FORM_data4)
.byte 0x0
.byte 0x0
.uleb128 0x4 # (abbrev code)
.uleb128 0x24 # (TAG: DW_TAG_base_type)
.byte 0x0 # DW_children_no
.uleb128 0x3 # (DW_AT_name)
.uleb128 0xe # (DW_FORM_strp)
.uleb128 0xb # (DW_AT_byte_size)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3e # (DW_AT_encoding)
.uleb128 0xb # (DW_FORM_data1)
.byte 0x0
.byte 0x0
.uleb128 0x5 # (abbrev code)
.uleb128 0x24 # (TAG: DW_TAG_base_type)
.byte 0x0 # DW_children_no
.uleb128 0x3 # (DW_AT_name)
.uleb128 0x8 # (DW_FORM_string)
.uleb128 0xb # (DW_AT_byte_size)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3e # (DW_AT_encoding)
.uleb128 0xb # (DW_FORM_data1)
.byte 0x0
.byte 0x0
.uleb128 0x6 # (abbrev code)
.uleb128 0x2e # (TAG: DW_TAG_subprogram)
.byte 0x0 # DW_children_no
.uleb128 0x3f # (DW_AT_external)
.uleb128 0xc # (DW_FORM_flag)
.uleb128 0x3 # (DW_AT_name)
.uleb128 0xe # (DW_FORM_strp)
.uleb128 0x3a # (DW_AT_decl_file)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3b # (DW_AT_decl_line)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
.uleb128 0x11 # (DW_AT_low_pc)
.uleb128 0x1 # (DW_FORM_addr)
.uleb128 0x12 # (DW_AT_high_pc)
.uleb128 0x1 # (DW_FORM_addr)
.uleb128 0x40 # (DW_AT_frame_base)
.uleb128 0xa # (DW_FORM_block1)
.byte 0x0
.byte 0x0
.uleb128 0x7 # (abbrev code)
.uleb128 0x34 # (TAG: DW_TAG_variable)
.byte 0x0 # DW_children_no
.uleb128 0x3 # (DW_AT_name)
.uleb128 0x8 # (DW_FORM_string)
.uleb128 0x3a # (DW_AT_decl_file)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3b # (DW_AT_decl_line)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
.uleb128 0x3f # (DW_AT_external)
.uleb128 0xc # (DW_FORM_flag)
.uleb128 0x2 # (DW_AT_location)
.uleb128 0xa # (DW_FORM_block1)
.byte 0x0
.byte 0x0
.uleb128 0x8 # (abbrev code)
.uleb128 0x35 # (TAG: DW_TAG_volatile_type)
.byte 0x0 # DW_children_no
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
.byte 0x0
.byte 0x0
.byte 0x0
.section .debug_pubnames,"",@progbits
.long 0x29 # Length of Public Names Info
.value 0x2 # DWARF Version
.long .Ldebug_info0 # Offset of Compilation Unit Info
.long 0xe7 # Compilation Unit Length
.long 0x25 # DIE offset
.ascii "func1\0" # external name
.long 0xb9 # DIE offset
.ascii "main\0" # external name
.long 0xcf # DIE offset
.ascii "vol\0" # external name
.long 0x0
.section .debug_aranges,"",@progbits
.long 0x1c # Length of Address Ranges Info
.value 0x2 # DWARF Version
.long .Ldebug_info0 # Offset of Compilation Unit Info
.byte 0x4 # Size of Address
.byte 0x0 # Size of Segment Descriptor
.value 0x0 # Pad to 8 byte boundary
.value 0x0
.long .Ltext0 # Address
.long .Letext0-.Ltext0 # Length
.long 0x0
.long 0x0
.section .debug_str,"MS",@progbits,1
.LASF4:
.string "main"
.LASF3:
.string "func1"
.LASF2:
.string "/local/zlomekj"
.LASF1:
.string "GNU C 3.4 20030924 (experimental)"
.LASF0:
.string "long int"
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4 20030924 (experimental)"
[-- Attachment #3: m-i386 --]
[-- Type: application/octet-stream, Size: 14709 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-01 15:44 ` Josef Zlomek
@ 2003-10-01 15:54 ` Daniel Jacobowitz
2003-10-01 16:03 ` Josef Zlomek
0 siblings, 1 reply; 16+ messages in thread
From: Daniel Jacobowitz @ 2003-10-01 15:54 UTC (permalink / raw)
To: Josef Zlomek; +Cc: gdb
On Wed, Oct 01, 2003 at 05:44:15PM +0200, Josef Zlomek wrote:
> > > Let the local variables and (some) arguments be addressed using stack pointer,
> > > for example x86-64 architecture with variables addressed using %rsp.
> > > The address emitted for variables located on stack by my new patch is always
> > > DW_OP_fbreg + constant.
> > >
> > > When I was testing the emitted debug info with mainline GDB I found that
> > > GDB probably does not adjust addresses of variables when stack pointer changes
> > > (like because of "pushq" instruction) if using location lists.
> > > I think GDB should adjust the address of %rsp addressed variables according to
> > > change of %rsp (probably DWARF2 sais so for DW_OP_fbreg). I think it is a
> > > better solution than emitting new locations to location list for all variables
> > > located on stack after each "push" and "pop" which would cause too large debug
> > > info.
> > >
> > > When I looked to gdb/dwarf2loc.c I see there:
> > > /* FIXME: cagney/2003-03-26: This code should be using
> > > get_frame_base_address(), and then implement a dwarf2 specific
> > > this_base method. */
> > > Probably this is related to my problem.
> >
> > The FIXME is a cleanliness problem. We do evaluate DW_AT_frame_base,
> > so it _ought_ to work.
> >
> > > I tested it on attached C file, assembler with debug info and x86-64 binary
> > > is attached too.
> >
> > Do you suppose you could produce an x86 (ia32) testcase? I don't have
> > x86-64 hardware available yet. The debug info looks right so I'd like
> > to get my fingers into the problem.
>
> Here is the x86 assembler.
Thanks. I'll get back to you... loading m-i386 into gdb and saying
"list" causes a segfault in dwarf2_read_section, so I have some
groundwork to do.
Blast! Location list support for paramaters (as opposed to locals) was
added to GDB after 6.0 branched, and I never thought to move it over.
It's too late now, so it will have to go in 6.0.1.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-01 15:54 ` Daniel Jacobowitz
@ 2003-10-01 16:03 ` Josef Zlomek
2003-10-01 16:22 ` Daniel Jacobowitz
0 siblings, 1 reply; 16+ messages in thread
From: Josef Zlomek @ 2003-10-01 16:03 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
> > > > Let the local variables and (some) arguments be addressed using stack pointer,
> > > > for example x86-64 architecture with variables addressed using %rsp.
> > > > The address emitted for variables located on stack by my new patch is always
> > > > DW_OP_fbreg + constant.
> > > >
> > > > When I was testing the emitted debug info with mainline GDB I found that
> > > > GDB probably does not adjust addresses of variables when stack pointer changes
> > > > (like because of "pushq" instruction) if using location lists.
> > > > I think GDB should adjust the address of %rsp addressed variables according to
> > > > change of %rsp (probably DWARF2 sais so for DW_OP_fbreg). I think it is a
> > > > better solution than emitting new locations to location list for all variables
> > > > located on stack after each "push" and "pop" which would cause too large debug
> > > > info.
> > > >
> > > > When I looked to gdb/dwarf2loc.c I see there:
> > > > /* FIXME: cagney/2003-03-26: This code should be using
> > > > get_frame_base_address(), and then implement a dwarf2 specific
> > > > this_base method. */
> > > > Probably this is related to my problem.
> > >
> > > The FIXME is a cleanliness problem. We do evaluate DW_AT_frame_base,
> > > so it _ought_ to work.
> > >
> > > > I tested it on attached C file, assembler with debug info and x86-64 binary
> > > > is attached too.
> > >
> > > Do you suppose you could produce an x86 (ia32) testcase? I don't have
> > > x86-64 hardware available yet. The debug info looks right so I'd like
> > > to get my fingers into the problem.
> >
> > Here is the x86 assembler.
>
> Thanks. I'll get back to you...
Thanks.
> Blast! Location list support for paramaters (as opposed to locals) was
> added to GDB after 6.0 branched, and I never thought to move it over.
> It's too late now, so it will have to go in 6.0.1.
No problem.
Josef
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-01 16:03 ` Josef Zlomek
@ 2003-10-01 16:22 ` Daniel Jacobowitz
2003-10-01 17:41 ` Josef Zlomek
0 siblings, 1 reply; 16+ messages in thread
From: Daniel Jacobowitz @ 2003-10-01 16:22 UTC (permalink / raw)
To: Josef Zlomek; +Cc: gdb
On Wed, Oct 01, 2003 at 06:03:18PM +0200, Josef Zlomek wrote:
> > > > > Let the local variables and (some) arguments be addressed using stack pointer,
> > > > > for example x86-64 architecture with variables addressed using %rsp.
> > > > > The address emitted for variables located on stack by my new patch is always
> > > > > DW_OP_fbreg + constant.
> > > > >
> > > > > When I was testing the emitted debug info with mainline GDB I found that
> > > > > GDB probably does not adjust addresses of variables when stack pointer changes
> > > > > (like because of "pushq" instruction) if using location lists.
> > > > > I think GDB should adjust the address of %rsp addressed variables according to
> > > > > change of %rsp (probably DWARF2 sais so for DW_OP_fbreg). I think it is a
> > > > > better solution than emitting new locations to location list for all variables
> > > > > located on stack after each "push" and "pop" which would cause too large debug
> > > > > info.
> > > > >
> > > > > When I looked to gdb/dwarf2loc.c I see there:
> > > > > /* FIXME: cagney/2003-03-26: This code should be using
> > > > > get_frame_base_address(), and then implement a dwarf2 specific
> > > > > this_base method. */
> > > > > Probably this is related to my problem.
> > > >
> > > > The FIXME is a cleanliness problem. We do evaluate DW_AT_frame_base,
> > > > so it _ought_ to work.
> > > >
> > > > > I tested it on attached C file, assembler with debug info and x86-64 binary
> > > > > is attached too.
> > > >
> > > > Do you suppose you could produce an x86 (ia32) testcase? I don't have
> > > > x86-64 hardware available yet. The debug info looks right so I'd like
> > > > to get my fingers into the problem.
> > >
> > > Here is the x86 assembler.
> >
> > Thanks. I'll get back to you...
>
> Thanks.
What makes you believe that GDB is the problem? Here's the debug info
for argument "g":
<2><8e>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : g
DW_AT_decl_file : 1
DW_AT_decl_line : 4
DW_AT_type : <ab>
DW_AT_location : 315 (location list)
Here's the location list:
0000013b 00000000 00000017 (DW_OP_fbreg: 28)
0000013b 00000017 00000083 (DW_OP_reg3)
0000013b 00000083 00000087 (DW_OP_fbreg: 28)
Here's the beginning of func1:
0x8048320 <func1>: push %ebp
0x8048321 <func1+1>: push %edi
0x8048322 <func1+2>: push %esi
0x8048323 <func1+3>: push %ebx
0x8048324 <func1+4>: sub $0x10,%esp
0x8048327 <func1+7>: mov 0x24(%esp,1),%eax
0x804832b <func1+11>: mov 0x2c(%esp,1),%edi
0x804832f <func1+15>: mov 0x38(%esp,1),%esi
i.e. those pushes are not accounted for in the debug info. This is
something that GCC must do when using -fomit-frame-pointer. To quote
from the DWARF spec:
The DW_OP_fbreg operation provides a signed LEB128 offset from the
address specified by the location description in the
DW_AT_frame_base attribute of the current function. (This is
typically a "stack pointer" register plus or minus some offset. On
more sophisticated systems it might be a location list that adjusts
the offset according to changes in the stack pointer as the PC
changes.)
The frame base is evaluated in the function's current context, not via
unwinding. So if GCC is using the CFA, then it needs to say so
somehow. It would be nice if it could reference the parent's stack
pointer somehow and save duplication. A mostly-relevant quote from the
spec:
In the context of supporting nested subroutines, the DW_AT_frame_base
attribute value should obey the following constraints:
1. It should compute a value that does not change during the life of
the procedure, and
>
> > Blast! Location list support for paramaters (as opposed to locals) was
> > added to GDB after 6.0 branched, and I never thought to move it over.
> > It's too late now, so it will have to go in 6.0.1.
>
> No problem.
>
> Josef
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-01 16:22 ` Daniel Jacobowitz
@ 2003-10-01 17:41 ` Josef Zlomek
2003-10-01 17:44 ` Daniel Jacobowitz
0 siblings, 1 reply; 16+ messages in thread
From: Josef Zlomek @ 2003-10-01 17:41 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
> What makes you believe that GDB is the problem? Here's the debug info
> for argument "g":
>
> <2><8e>: Abbrev Number: 3 (DW_TAG_formal_parameter)
> DW_AT_name : g
> DW_AT_decl_file : 1
> DW_AT_decl_line : 4
> DW_AT_type : <ab>
> DW_AT_location : 315 (location list)
>
> Here's the location list:
> 0000013b 00000000 00000017 (DW_OP_fbreg: 28)
> 0000013b 00000017 00000083 (DW_OP_reg3)
> 0000013b 00000083 00000087 (DW_OP_fbreg: 28)
>
> Here's the beginning of func1:
> 0x8048320 <func1>: push %ebp
> 0x8048321 <func1+1>: push %edi
> 0x8048322 <func1+2>: push %esi
> 0x8048323 <func1+3>: push %ebx
> 0x8048324 <func1+4>: sub $0x10,%esp
> 0x8048327 <func1+7>: mov 0x24(%esp,1),%eax
> 0x804832b <func1+11>: mov 0x2c(%esp,1),%edi
> 0x804832f <func1+15>: mov 0x38(%esp,1),%esi
>
> i.e. those pushes are not accounted for in the debug info. This is
> something that GCC must do when using -fomit-frame-pointer.
I did not write the part generating the location lists, I do not know DRARF
much. I thought that the labels LCFIx after each push mean adjustment of the
frame pointer.
.LVL0:
# basic block 0
pushl %ebp
.LCFI0:
pushl %edi
.LCFI1:
pushl %esi
> To quote from the DWARF spec:
>
> The DW_OP_fbreg operation provides a signed LEB128 offset from the
> address specified by the location description in the
> DW_AT_frame_base attribute of the current function. (This is
> typically a "stack pointer" register plus or minus some offset. On
> more sophisticated systems it might be a location list that adjusts
> the offset according to changes in the stack pointer as the PC
> changes.)
>
> The frame base is evaluated in the function's current context, not via
> unwinding. So if GCC is using the CFA, then it needs to say so
> somehow. It would be nice if it could reference the parent's stack
> pointer somehow and save duplication. A mostly-relevant quote from the
> spec:
>
> In the context of supporting nested subroutines, the DW_AT_frame_base
> attribute value should obey the following constraints:
>
> 1. It should compute a value that does not change during the life of
> the procedure, and
So shall the location for all variables located on stack be reemitted with the
changed offset after each push/pop? That would mean longer debug info.
I thought better idea would be adjusting the offsets from frame base in GDB.
Josef
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-01 17:41 ` Josef Zlomek
@ 2003-10-01 17:44 ` Daniel Jacobowitz
2003-10-01 17:48 ` Josef Zlomek
2003-10-06 6:22 ` Richard Henderson
0 siblings, 2 replies; 16+ messages in thread
From: Daniel Jacobowitz @ 2003-10-01 17:44 UTC (permalink / raw)
To: Josef Zlomek; +Cc: gdb
On Wed, Oct 01, 2003 at 07:41:42PM +0200, Josef Zlomek wrote:
> > What makes you believe that GDB is the problem? Here's the debug info
> > for argument "g":
> >
> > <2><8e>: Abbrev Number: 3 (DW_TAG_formal_parameter)
> > DW_AT_name : g
> > DW_AT_decl_file : 1
> > DW_AT_decl_line : 4
> > DW_AT_type : <ab>
> > DW_AT_location : 315 (location list)
> >
> > Here's the location list:
> > 0000013b 00000000 00000017 (DW_OP_fbreg: 28)
> > 0000013b 00000017 00000083 (DW_OP_reg3)
> > 0000013b 00000083 00000087 (DW_OP_fbreg: 28)
> >
> > Here's the beginning of func1:
> > 0x8048320 <func1>: push %ebp
> > 0x8048321 <func1+1>: push %edi
> > 0x8048322 <func1+2>: push %esi
> > 0x8048323 <func1+3>: push %ebx
> > 0x8048324 <func1+4>: sub $0x10,%esp
> > 0x8048327 <func1+7>: mov 0x24(%esp,1),%eax
> > 0x804832b <func1+11>: mov 0x2c(%esp,1),%edi
> > 0x804832f <func1+15>: mov 0x38(%esp,1),%esi
> >
> > i.e. those pushes are not accounted for in the debug info. This is
> > something that GCC must do when using -fomit-frame-pointer.
>
> I did not write the part generating the location lists, I do not know DRARF
> much. I thought that the labels LCFIx after each push mean adjustment of the
> frame pointer.
>
> .LVL0:
> # basic block 0
> pushl %ebp
> .LCFI0:
> pushl %edi
> .LCFI1:
> pushl %esi
They do. But they're not used for debug information (.debug_info);
only for .debug_frame, which is _unwind_ information.
> > To quote from the DWARF spec:
> >
> > The DW_OP_fbreg operation provides a signed LEB128 offset from the
> > address specified by the location description in the
> > DW_AT_frame_base attribute of the current function. (This is
> > typically a "stack pointer" register plus or minus some offset. On
> > more sophisticated systems it might be a location list that adjusts
> > the offset according to changes in the stack pointer as the PC
> > changes.)
> >
> > The frame base is evaluated in the function's current context, not via
> > unwinding. So if GCC is using the CFA, then it needs to say so
> > somehow. It would be nice if it could reference the parent's stack
> > pointer somehow and save duplication. A mostly-relevant quote from the
> > spec:
> >
> > In the context of supporting nested subroutines, the DW_AT_frame_base
> > attribute value should obey the following constraints:
> >
> > 1. It should compute a value that does not change during the life of
> > the procedure, and
>
> So shall the location for all variables located on stack be reemitted with the
> changed offset after each push/pop? That would mean longer debug info.
> I thought better idea would be adjusting the offsets from frame base in GDB.
No, but DW_AT_frame_base should be a location list describing the
changes in the frame base.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-01 17:44 ` Daniel Jacobowitz
@ 2003-10-01 17:48 ` Josef Zlomek
2003-10-06 6:22 ` Richard Henderson
1 sibling, 0 replies; 16+ messages in thread
From: Josef Zlomek @ 2003-10-01 17:48 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
> > > The frame base is evaluated in the function's current context, not via
> > > unwinding. So if GCC is using the CFA, then it needs to say so
> > > somehow. It would be nice if it could reference the parent's stack
> > > pointer somehow and save duplication. A mostly-relevant quote from the
> > > spec:
> > >
> > > In the context of supporting nested subroutines, the DW_AT_frame_base
> > > attribute value should obey the following constraints:
> > >
> > > 1. It should compute a value that does not change during the life of
> > > the procedure, and
> >
> > So shall the location for all variables located on stack be reemitted with the
> > changed offset after each push/pop? That would mean longer debug info.
> > I thought better idea would be adjusting the offsets from frame base in GDB.
>
> No, but DW_AT_frame_base should be a location list describing the
> changes in the frame base.
I see. Thanks!
Josef
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-01 17:44 ` Daniel Jacobowitz
2003-10-01 17:48 ` Josef Zlomek
@ 2003-10-06 6:22 ` Richard Henderson
2003-10-06 6:40 ` Josef Zlomek
1 sibling, 1 reply; 16+ messages in thread
From: Richard Henderson @ 2003-10-06 6:22 UTC (permalink / raw)
To: Josef Zlomek, gdb
On Wed, Oct 01, 2003 at 01:44:27PM -0400, Daniel Jacobowitz wrote:
> No, but DW_AT_frame_base should be a location list describing the
> changes in the frame base.
How can we just describe "please use the CFA" and avoid duplicating
this part of the unwind info?
r~
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-06 6:22 ` Richard Henderson
@ 2003-10-06 6:40 ` Josef Zlomek
2003-10-06 13:46 ` Daniel Jacobowitz
0 siblings, 1 reply; 16+ messages in thread
From: Josef Zlomek @ 2003-10-06 6:40 UTC (permalink / raw)
To: Richard Henderson; +Cc: gdb
> > No, but DW_AT_frame_base should be a location list describing the
> > changes in the frame base.
>
> How can we just describe "please use the CFA" and avoid duplicating
> this part of the unwind info?
Daniel Berlin has already written support for GCC to generate location
list for DW_AT_frame_base.
DW_AT_frame_base is a location list as any other (actually only the
offsets relatively to original stack pointer at function start are needed).
GDB then uses this location list to adjust offsets of other variables
addressed using stack pointer.
With Daniel Jacobowitz's fix for GDB it works :-)
i.e. you can see correct values for variables located on stack
even when stack pointer changes because of push, pop, etc.
Current GCC patch can be downloaded from:
http://artax.karlin.mff.cuni.cz/~zlomj9am/download/vt-main.patch
(because currently GCC is in stage 2 it has to wait until GCC is in stage 1)
Josef
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-06 6:40 ` Josef Zlomek
@ 2003-10-06 13:46 ` Daniel Jacobowitz
2003-10-06 14:49 ` Daniel Berlin
0 siblings, 1 reply; 16+ messages in thread
From: Daniel Jacobowitz @ 2003-10-06 13:46 UTC (permalink / raw)
To: Josef Zlomek; +Cc: Richard Henderson, gdb
On Mon, Oct 06, 2003 at 08:40:16AM +0200, Josef Zlomek wrote:
> > > No, but DW_AT_frame_base should be a location list describing the
> > > changes in the frame base.
> >
> > How can we just describe "please use the CFA" and avoid duplicating
> > this part of the unwind info?
Yea, I'd like that too. We can't right now, but it seems reasonable,
so I'll propose it on the DWARF-2 list. Until then it's just a space
cost.
> Daniel Berlin has already written support for GCC to generate location
> list for DW_AT_frame_base.
> DW_AT_frame_base is a location list as any other (actually only the
> offsets relatively to original stack pointer at function start are needed).
> GDB then uses this location list to adjust offsets of other variables
> addressed using stack pointer.
> With Daniel Jacobowitz's fix for GDB it works :-)
> i.e. you can see correct values for variables located on stack
> even when stack pointer changes because of push, pop, etc.
>
> Current GCC patch can be downloaded from:
> http://artax.karlin.mff.cuni.cz/~zlomj9am/download/vt-main.patch
>
> (because currently GCC is in stage 2 it has to wait until GCC is in stage 1)
I suppose this is true, but it's really unfortunate.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-06 13:46 ` Daniel Jacobowitz
@ 2003-10-06 14:49 ` Daniel Berlin
2003-10-07 21:48 ` Daniel Jacobowitz
0 siblings, 1 reply; 16+ messages in thread
From: Daniel Berlin @ 2003-10-06 14:49 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Richard Henderson, gdb, Josef Zlomek
>> Daniel Berlin has already written support for GCC to generate location
>> list for DW_AT_frame_base.
>> DW_AT_frame_base is a location list as any other (actually only the
>> offsets relatively to original stack pointer at function start are
>> needed).
>> GDB then uses this location list to adjust offsets of other variables
>> addressed using stack pointer.
>> With Daniel Jacobowitz's fix for GDB it works :-)
>> i.e. you can see correct values for variables located on stack
>> even when stack pointer changes because of push, pop, etc.
>>
>> Current GCC patch can be downloaded from:
>> http://artax.karlin.mff.cuni.cz/~zlomj9am/download/vt-main.patch
>>
>> (because currently GCC is in stage 2 it has to wait until GCC is in
>> stage 1)
>
> I suppose this is true, but it's really unfortunate.
I'm not so sure it's true.
This isn't a major change, really and it's only going to make things
better (We didn't use to support -O2 -g at all, really, and now we can.
There can't be any regressions from an unsupported state to a
supported one). It's also not an optimization pass, so the risk is
relatively low.
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-06 14:49 ` Daniel Berlin
@ 2003-10-07 21:48 ` Daniel Jacobowitz
2003-10-08 5:09 ` Josef Zlomek
0 siblings, 1 reply; 16+ messages in thread
From: Daniel Jacobowitz @ 2003-10-07 21:48 UTC (permalink / raw)
To: Daniel Berlin, Josef Zlomek; +Cc: Richard Henderson, gdb
On Mon, Oct 06, 2003 at 10:48:12AM -0400, Daniel Berlin wrote:
> >>Daniel Berlin has already written support for GCC to generate location
> >>list for DW_AT_frame_base.
> >>DW_AT_frame_base is a location list as any other (actually only the
> >>offsets relatively to original stack pointer at function start are
> >>needed).
> >>GDB then uses this location list to adjust offsets of other variables
> >>addressed using stack pointer.
> >>With Daniel Jacobowitz's fix for GDB it works :-)
> >>i.e. you can see correct values for variables located on stack
> >>even when stack pointer changes because of push, pop, etc.
> >>
> >>Current GCC patch can be downloaded from:
> >>http://artax.karlin.mff.cuni.cz/~zlomj9am/download/vt-main.patch
> >>
> >>(because currently GCC is in stage 2 it has to wait until GCC is in
> >>stage 1)
> >
> >I suppose this is true, but it's really unfortunate.
>
> I'm not so sure it's true.
>
> This isn't a major change, really and it's only going to make things
> better (We didn't use to support -O2 -g at all, really, and now we can.
> There can't be any regressions from an unsupported state to a
> supported one). It's also not an optimization pass, so the risk is
> relatively low.
Well, FWIW I'd like to see this included. Josef, do you have any
interest in submiting it for 3.4, to see what reaction it gets at least?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with location lists and variables on stack
2003-10-07 21:48 ` Daniel Jacobowitz
@ 2003-10-08 5:09 ` Josef Zlomek
0 siblings, 0 replies; 16+ messages in thread
From: Josef Zlomek @ 2003-10-08 5:09 UTC (permalink / raw)
To: Daniel Berlin, Richard Henderson, gdb
> > >>Daniel Berlin has already written support for GCC to generate location
> > >>list for DW_AT_frame_base.
> > >>DW_AT_frame_base is a location list as any other (actually only the
> > >>offsets relatively to original stack pointer at function start are
> > >>needed).
> > >>GDB then uses this location list to adjust offsets of other variables
> > >>addressed using stack pointer.
> > >>With Daniel Jacobowitz's fix for GDB it works :-)
> > >>i.e. you can see correct values for variables located on stack
> > >>even when stack pointer changes because of push, pop, etc.
> > >>
> > >>Current GCC patch can be downloaded from:
> > >>http://artax.karlin.mff.cuni.cz/~zlomj9am/download/vt-main.patch
> > >>
> > >>(because currently GCC is in stage 2 it has to wait until GCC is in
> > >>stage 1)
> > >
> > >I suppose this is true, but it's really unfortunate.
> >
> > I'm not so sure it's true.
> >
> > This isn't a major change, really and it's only going to make things
> > better (We didn't use to support -O2 -g at all, really, and now we can.
> > There can't be any regressions from an unsupported state to a
> > supported one). It's also not an optimization pass, so the risk is
> > relatively low.
>
> Well, FWIW I'd like to see this included. Josef, do you have any
> interest in submiting it for 3.4, to see what reaction it gets at least?
I'll try to submit it for 3.4. If it is disabled for default and
enabled only explicitelly with -fvar-tracking the risk of breaking
something will be very low.
Anyway, I'm planning to commit it to hammer-3_3-branch (enabled by default)
as soon as I backport some patches needed by variable tracking from
mainline.
Josef
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2003-10-08 5:09 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-01 14:43 Problem with location lists and variables on stack Josef Zlomek
2003-10-01 14:49 ` Daniel Jacobowitz
2003-10-01 15:21 ` Josef Zlomek
2003-10-01 15:44 ` Josef Zlomek
2003-10-01 15:54 ` Daniel Jacobowitz
2003-10-01 16:03 ` Josef Zlomek
2003-10-01 16:22 ` Daniel Jacobowitz
2003-10-01 17:41 ` Josef Zlomek
2003-10-01 17:44 ` Daniel Jacobowitz
2003-10-01 17:48 ` Josef Zlomek
2003-10-06 6:22 ` Richard Henderson
2003-10-06 6:40 ` Josef Zlomek
2003-10-06 13:46 ` Daniel Jacobowitz
2003-10-06 14:49 ` Daniel Berlin
2003-10-07 21:48 ` Daniel Jacobowitz
2003-10-08 5:09 ` Josef Zlomek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox