* Broken .loc directive in GAS
@ 2003-07-10 15:36 Michal Ludvig
2003-07-10 16:52 ` Richard Henderson
0 siblings, 1 reply; 8+ messages in thread
From: Michal Ludvig @ 2003-07-10 15:36 UTC (permalink / raw)
To: binutils
[-- Attachment #1: Type: text/plain, Size: 3220 bytes --]
Hi all,
while investigating a GDB testsuite failure I found out that .debug_line
section can sometimes be broken.
Take the example code temp.cc and compile it to temp.o:
$ g++ -g -c temp.cc
Inspecting .debug_line with 'readelf -wl temp.o' shows this:
[...]
Line Number Statements:
Extended opcode 2: set Address to 0x0
Special opcode 13: advance Address by 0 to 0x0 and Line by 8 to 9
Advance PC by 14 to e
Extended opcode 1: End of Sequence
Extended opcode 2: set Address to 0x0
Special opcode 13: advance Address by 0 to 0x0 and Line by 8 to 9
Advance PC by 14 to e
Extended opcode 1: End of Sequence
Extended opcode 2: set Address to 0x0
Advance Line by 16 to 17
Copy
Special opcode 62: advance Address by 4 to 0x4 and Line by 1 to 18
Special opcode 76: advance Address by 5 to 0x9 and Line by 1 to 19
Advance Line by -6 to 13
Special opcode 47: advance Address by 3 to 0xc and Line by 0 to 13
Special opcode 201: advance Address by 14 to 0x1a and Line by 0 to 13
Advance PC by constant 17 to 0x2b
Special opcode 215: advance Address by 15 to 0x3a and Line by 0 to 13
Special opcode 61: advance Address by 4 to 0x3e and Line by 0 to 13
Advance PC by 20 to 52
Extended opcode 1: End of Sequence
[...]
First two sequences are for constructors' sections and the third is for
the .text section.
What I don't understand are the last two lines in .text section, i.e.
Advance PC by 20 to 52
Extended opcode 1: End of Sequence
How does the GAS know it should advance the PC by 20? It probably
ment something like "Advance PC to the end of the section". Offset
0x52 points 2 bytes beyond the end of the section which triggers
problems when the file is linked:
$ g++ -o temp temp.o
$ readelf -wl temp
Then the .debug_line section (relevant part) is like this:
[...]
Extended opcode 2: set Address to 0x400546
[...]
Extended opcode 1: End of Sequence
Extended opcode 2: set Address to 0x400538
Special opcode 13: advance Address by 0 to 0x400538 and Line by 8 to 9
Advance PC by 14 to 400546
Extended opcode 1: End of Sequence
Extended opcode 2: set Address to 0x4004e8
[...]
Special opcode 61: advance Address by 4 to 0x400526 and Line by 0 to 13
Advance PC by 20 to 40053a
Extended opcode 1: End of Sequence
[...]
As you can see - second sequence starts at 0x400538 but third sequence
ends at 40053a, i.e. they overlap by two bytes. This confuses GDB
because it sorts the line numbers by their PC and overlapping sequences
don't make sense.
Everything written so far was seen on AMD64. However you can observe
exactly the same problem (off-by-2) on i386 as well.
The only difference is that i386 GCC puts another .loc mark right after
the function prologue, which is 3 bytes long, which eliminates the GDB
problem. This is not a correct solution however.
I suspect something is broken in the GAS - does anyone know these line
numbering internals?
I'm using gcc-3.3 and recent a snapshot of binutils (2.14.90 20030710)
but the version from January gives the same output.
Thans in advance for any hint!
Michal Ludvig
--
* SuSE CR, s.r.o * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz
[-- Attachment #2: temp.cc --]
[-- Type: text/plain, Size: 167 bytes --]
template<class T>
class T5 {
public:
T5(int);
};
template<class T>
T5<T>::T5(int val)
{
}
T5<int> t5i(2);
template class T5<int>;
int main()
{
return 0;
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Broken .loc directive in GAS
2003-07-10 15:36 Broken .loc directive in GAS Michal Ludvig
@ 2003-07-10 16:52 ` Richard Henderson
2003-07-11 6:27 ` Michal Ludvig
0 siblings, 1 reply; 8+ messages in thread
From: Richard Henderson @ 2003-07-10 16:52 UTC (permalink / raw)
To: Michal Ludvig; +Cc: binutils
On Thu, Jul 10, 2003 at 05:36:08PM +0200, Michal Ludvig wrote:
> What I don't understand are the last two lines in .text section, i.e.
> Advance PC by 20 to 52
> Extended opcode 1: End of Sequence
>
> How does the GAS know it should advance the PC by 20? It probably
> ment something like "Advance PC to the end of the section".
Yes.
> Offset 0x52 points 2 bytes beyond the end of the section ...
Well, that would be a bug, certainly. Test case?
r~
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Broken .loc directive in GAS
2003-07-10 16:52 ` Richard Henderson
@ 2003-07-11 6:27 ` Michal Ludvig
2003-07-11 11:43 ` Alan Modra
0 siblings, 1 reply; 8+ messages in thread
From: Michal Ludvig @ 2003-07-11 6:27 UTC (permalink / raw)
To: Richard Henderson; +Cc: binutils
[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]
Richard Henderson told me that:
> On Thu, Jul 10, 2003 at 05:36:08PM +0200, Michal Ludvig wrote:
>>Offset 0x52 points 2 bytes beyond the end of the section ...
>
> Well, that would be a bug, certainly. Test case?
Test case was in my first posting - attached file temp.cc (attaching it
once again). Compile it either on i386 or amd64 (both on SuSE Linux 8.2,
but using compilers and binutils from CVS) and link it. Then examine the
resulting 'temp' elf file via 'readelf -wl temp' and look for
information about 'temp.cc' file:
**********
The File Name Table:
Entry Dir Time Size Name
1 0 0 0 temp.cc
Line Number Statements:
Extended opcode 2: set Address to 0x80483c6
Special opcode 13: advance Address by 0 to 0x80483c6 and Line by 8 to 9
Special opcode 47: advance Address by 3 to 0x80483c9 and Line by 0 to 9
Advance PC by 3 to 80483cc
Extended opcode 1: End of Sequence
Extended opcode 2: set Address to 0x80483c0
Special opcode 13: advance Address by 0 to 0x80483c0 and Line by 8 to 9
Special opcode 47: advance Address by 3 to 0x80483c3 and Line by 0 to 9
Advance PC by 3 to 80483c6
Extended opcode 1: End of Sequence
Extended opcode 2: set Address to 0x8048364
Advance Line by 16 to 17
Copy
Special opcode 230: advance Address by 16 to 0x8048374 and Line by 1
to 18
[...]
Special opcode 89: advance Address by 6 to 0x80483ac and Line by 0 to 13
Advance PC by 22 to 80483c2
Extended opcode 1: End of Sequence
**********
As you can see - second sequence begins at 0x80483c0 while the third one
ends at 80483c2, i.e. two bytes beyond the start of the second sequence.
(i386 addresses).
Is this a valid testcase?
Michal Ludvig
--
* SuSE CR, s.r.o * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz
[-- Attachment #2: temp.cc --]
[-- Type: text/plain, Size: 167 bytes --]
template<class T>
class T5 {
public:
T5(int);
};
template<class T>
T5<T>::T5(int val)
{
}
T5<int> t5i(2);
template class T5<int>;
int main()
{
return 0;
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Broken .loc directive in GAS
2003-07-11 6:27 ` Michal Ludvig
@ 2003-07-11 11:43 ` Alan Modra
2003-07-11 15:16 ` Michal Ludvig
2003-07-15 15:20 ` Michal Ludvig
0 siblings, 2 replies; 8+ messages in thread
From: Alan Modra @ 2003-07-11 11:43 UTC (permalink / raw)
To: Michal Ludvig; +Cc: binutils
[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]
On Fri, Jul 11, 2003 at 08:27:50AM +0200, Michal Ludvig wrote:
> Richard Henderson told me that:
> >On Thu, Jul 10, 2003 at 05:36:08PM +0200, Michal Ludvig wrote:
> >>Offset 0x52 points 2 bytes beyond the end of the section ...
> >
> >Well, that would be a bug, certainly. Test case?
>
> Test case was in my first posting - attached file temp.cc (attaching it
I don't see any problem with current gcc-3.3 and mainline, and an older
gcc-3.3. Current mainline gives:
The File Name Table:
Entry Dir Time Size Name
1 1 0 0 temp.cc
Line Number Statements:
Extended opcode 2: set Address to 0x80483ba
Special opcode 13: advance Address by 0 to 0x80483ba and Line by 8 to 9
Advance PC by 6 to 80483c0
Extended opcode 1: End of Sequence
Extended opcode 2: set Address to 0x80483b4
Special opcode 13: advance Address by 0 to 0x80483b4 and Line by 8 to 9
Advance PC by 6 to 80483ba
Extended opcode 1: End of Sequence
Extended opcode 2: set Address to 0x8048354
Advance Line by 16 to 17
Copy
Special opcode 230: advance Address by 16 to 0x8048364 and Line by 1 to 18
Special opcode 76: advance Address by 5 to 0x8048369 and Line by 1 to 19
Special opcode 48: advance Address by 3 to 0x804836c and Line by 1 to 20
Advance Line by -7 to 13
Special opcode 89: advance Address by 6 to 0x8048372 and Line by 0 to 13
Advance PC by 35 to 8048395
Special opcode 12: advance Address by 0 to 0x8048395 and Line by 7 to 20
Special opcode 48: advance Address by 3 to 0x8048398 and Line by 1 to 21
Advance PC by 28 to 80483b4
Extended opcode 1: End of Sequence
For reference, I've attached the -S output I get from your testcase.
I suppose it's possible that ld is being confused by your crt*, libgcc
or libc.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
[-- Attachment #2: temp.s --]
[-- Type: text/plain, Size: 10191 bytes --]
.file "temp.cc"
.section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
.section .debug_info,"",@progbits
.Ldebug_info0:
.section .debug_line,"",@progbits
.Ldebug_line0:
.text
.Ltext0:
.globl t5i
.bss
.type t5i, @object
.size t5i, 1
t5i:
.zero 1
.text
.align 2
.globl main
.type main, @function
main:
.LFB4:
.LBB2:
.file 1 "/src/tmp/temp.cc"
.loc 1 17 0
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
subl $8, %esp
.LCFI2:
andl $-16, %esp
movl $0, %eax
subl %eax, %esp
.loc 1 18 0
movl $0, %eax
.LBE2:
.loc 1 19 0
leave
ret
.LFE4:
.size main, .-main
.section .gnu.linkonce.t._ZN2T5IiEC2Ei,"ax",@progbits
.align 2
.weak _ZN2T5IiEC2Ei
.type _ZN2T5IiEC2Ei, @function
_ZN2T5IiEC2Ei:
.LFB7:
.loc 1 9 0
pushl %ebp
.LCFI3:
movl %esp, %ebp
.LCFI4:
popl %ebp
ret
.LFE7:
.size _ZN2T5IiEC2Ei, .-_ZN2T5IiEC2Ei
.section .gnu.linkonce.t._ZN2T5IiEC1Ei,"ax",@progbits
.align 2
.weak _ZN2T5IiEC1Ei
.type _ZN2T5IiEC1Ei, @function
_ZN2T5IiEC1Ei:
.LFB9:
.loc 1 9 0
pushl %ebp
.LCFI5:
movl %esp, %ebp
.LCFI6:
popl %ebp
ret
.LFE9:
.size _ZN2T5IiEC1Ei, .-_ZN2T5IiEC1Ei
.text
.align 2
.type _Z41__static_initialization_and_destruction_0ii, @function
_Z41__static_initialization_and_destruction_0ii:
.LFB11:
.loc 1 20 0
pushl %ebp
.LCFI7:
movl %esp, %ebp
.LCFI8:
subl $8, %esp
.LCFI9:
.loc 1 13 0
cmpl $65535, 12(%ebp)
jne .L4
cmpl $1, 8(%ebp)
jne .L4
movl $2, 4(%esp)
movl $t5i, (%esp)
call _ZN2T5IiEC1Ei
.L4:
.loc 1 20 0
leave
ret
.LFE11:
.size _Z41__static_initialization_and_destruction_0ii, .-_Z41__static_initialization_and_destruction_0ii
.align 2
.type _GLOBAL__I_t5i, @function
_GLOBAL__I_t5i:
.LFB13:
.loc 1 21 0
pushl %ebp
.LCFI10:
movl %esp, %ebp
.LCFI11:
subl $8, %esp
.LCFI12:
movl $65535, 4(%esp)
movl $1, (%esp)
call _Z41__static_initialization_and_destruction_0ii
leave
ret
.LFE13:
.size _GLOBAL__I_t5i, .-_GLOBAL__I_t5i
.section .ctors,"aw",@progbits
.align 4
.long _GLOBAL__I_t5i
.section .debug_frame,"",@progbits
.Lframe0:
.long .LECIE0-.LSCIE0
.LSCIE0:
.long 0xffffffff
.byte 0x1
.string ""
.uleb128 0x1
.sleb128 -4
.byte 0x8
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.byte 0x88
.uleb128 0x1
.align 4
.LECIE0:
.LSFDE0:
.long .LEFDE0-.LASFDE0
.LASFDE0:
.long .Lframe0
.long .LFB4
.long .LFE4-.LFB4
.byte 0x4
.long .LCFI0-.LFB4
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI1-.LCFI0
.byte 0xd
.uleb128 0x5
.align 4
.LEFDE0:
.LSFDE2:
.long .LEFDE2-.LASFDE2
.LASFDE2:
.long .Lframe0
.long .LFB7
.long .LFE7-.LFB7
.byte 0x4
.long .LCFI3-.LFB7
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI4-.LCFI3
.byte 0xd
.uleb128 0x5
.align 4
.LEFDE2:
.LSFDE4:
.long .LEFDE4-.LASFDE4
.LASFDE4:
.long .Lframe0
.long .LFB9
.long .LFE9-.LFB9
.byte 0x4
.long .LCFI5-.LFB9
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI6-.LCFI5
.byte 0xd
.uleb128 0x5
.align 4
.LEFDE4:
.LSFDE6:
.long .LEFDE6-.LASFDE6
.LASFDE6:
.long .Lframe0
.long .LFB11
.long .LFE11-.LFB11
.byte 0x4
.long .LCFI7-.LFB11
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI8-.LCFI7
.byte 0xd
.uleb128 0x5
.align 4
.LEFDE6:
.LSFDE8:
.long .LEFDE8-.LASFDE8
.LASFDE8:
.long .Lframe0
.long .LFB13
.long .LFE13-.LFB13
.byte 0x4
.long .LCFI10-.LFB13
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI11-.LCFI10
.byte 0xd
.uleb128 0x5
.align 4
.LEFDE8:
.text
.Letext0:
.section .debug_info
.long 0x1ed
.value 0x2
.long .Ldebug_abbrev0
.byte 0x4
.uleb128 0x1
.long .Ldebug_line0
.string "GNU C++ 3.4 20030710 (experimental)"
.byte 0x4
.string "/src/tmp/temp.cc"
.uleb128 0x2
.long 0xb6
.string "T5<int>"
.byte 0x1
.byte 0x1
.byte 0x2
.uleb128 0x3
.long 0x8a
.byte 0x1
.string "operator="
.string "_ZN2T5IiEaSERKS0_"
.long 0xb6
.byte 0x1
.byte 0x1
.uleb128 0x4
.long 0xbc
.byte 0x1
.uleb128 0x5
.long 0xc2
.byte 0x0
.uleb128 0x6
.long 0xa1
.byte 0x1
.string "T5"
.byte 0x1
.byte 0x1
.uleb128 0x4
.long 0xbc
.byte 0x1
.uleb128 0x5
.long 0xc2
.byte 0x0
.uleb128 0x7
.byte 0x1
.string "T5"
.byte 0x1
.byte 0x9
.byte 0x1
.uleb128 0x4
.long 0xbc
.byte 0x1
.uleb128 0x5
.long 0xcd
.byte 0x0
.byte 0x0
.uleb128 0x8
.byte 0x4
.long 0x46
.uleb128 0x9
.byte 0x4
.long 0x46
.uleb128 0x8
.byte 0x4
.long 0xc8
.uleb128 0xa
.long 0x46
.uleb128 0xb
.string "int"
.byte 0x4
.byte 0x5
.uleb128 0xc
.byte 0x1
.string "main"
.byte 0x1
.byte 0x11
.long 0xcd
.long .LFB4
.long .LFE4
.byte 0x1
.byte 0x55
.uleb128 0xd
.long 0x10c
.long 0xa1
.byte 0x2
.uleb128 0xe
.string "this"
.long 0x10c
.byte 0x1
.uleb128 0xf
.string "val"
.byte 0x1
.byte 0x9
.long 0xcd
.byte 0x0
.uleb128 0xa
.long 0xbc
.uleb128 0x10
.long 0x135
.long 0xeb
.long .LFB7
.long .LFE7
.byte 0x1
.byte 0x55
.uleb128 0x11
.long 0xf5
.byte 0x2
.byte 0x91
.sleb128 8
.uleb128 0x11
.long 0x100
.byte 0x2
.byte 0x91
.sleb128 12
.byte 0x0
.uleb128 0x10
.long 0x159
.long 0xeb
.long .LFB9
.long .LFE9
.byte 0x1
.byte 0x55
.uleb128 0x11
.long 0xf5
.byte 0x2
.byte 0x91
.sleb128 8
.uleb128 0x11
.long 0x100
.byte 0x2
.byte 0x91
.sleb128 12
.byte 0x0
.uleb128 0x12
.long 0x1c2
.string "__static_initialization_and_destruction_0"
.byte 0x1
.long .LFB11
.long .LFE11
.byte 0x1
.byte 0x55
.uleb128 0x13
.string "__initialize_p"
.byte 0x1
.byte 0x14
.long 0xcd
.byte 0x2
.byte 0x91
.sleb128 8
.uleb128 0x13
.string "__priority"
.byte 0x1
.byte 0x14
.long 0xcd
.byte 0x2
.byte 0x91
.sleb128 12
.byte 0x0
.uleb128 0x14
.string "_GLOBAL__I_t5i"
.byte 0x1
.byte 0x15
.long .LFB13
.long .LFE13
.byte 0x1
.byte 0x55
.uleb128 0x15
.string "t5i"
.byte 0x1
.byte 0xd
.long 0x46
.byte 0x1
.byte 0x5
.byte 0x3
.long t5i
.byte 0x0
.section .debug_abbrev
.uleb128 0x1
.uleb128 0x11
.byte 0x1
.uleb128 0x10
.uleb128 0x6
.uleb128 0x25
.uleb128 0x8
.uleb128 0x13
.uleb128 0xb
.uleb128 0x3
.uleb128 0x8
.byte 0x0
.byte 0x0
.uleb128 0x2
.uleb128 0x13
.byte 0x1
.uleb128 0x1
.uleb128 0x13
.uleb128 0x3
.uleb128 0x8
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0x3
.uleb128 0x2e
.byte 0x1
.uleb128 0x1
.uleb128 0x13
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0x8
.uleb128 0x2007
.uleb128 0x8
.uleb128 0x49
.uleb128 0x13
.uleb128 0x34
.uleb128 0xc
.uleb128 0x3c
.uleb128 0xc
.byte 0x0
.byte 0x0
.uleb128 0x4
.uleb128 0x5
.byte 0x0
.uleb128 0x49
.uleb128 0x13
.uleb128 0x34
.uleb128 0xc
.byte 0x0
.byte 0x0
.uleb128 0x5
.uleb128 0x5
.byte 0x0
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0x6
.uleb128 0x2e
.byte 0x1
.uleb128 0x1
.uleb128 0x13
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0x8
.uleb128 0x34
.uleb128 0xc
.uleb128 0x3c
.uleb128 0xc
.byte 0x0
.byte 0x0
.uleb128 0x7
.uleb128 0x2e
.byte 0x1
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x3c
.uleb128 0xc
.byte 0x0
.byte 0x0
.uleb128 0x8
.uleb128 0x10
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0x9
.uleb128 0xf
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0xa
.uleb128 0x26
.byte 0x0
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0xb
.uleb128 0x24
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0xc
.uleb128 0x2e
.byte 0x0
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0xd
.uleb128 0x2e
.byte 0x1
.uleb128 0x1
.uleb128 0x13
.uleb128 0x47
.uleb128 0x13
.uleb128 0x20
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0xe
.uleb128 0x5
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x49
.uleb128 0x13
.uleb128 0x34
.uleb128 0xc
.byte 0x0
.byte 0x0
.uleb128 0xf
.uleb128 0x5
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0x10
.uleb128 0x2e
.byte 0x1
.uleb128 0x1
.uleb128 0x13
.uleb128 0x31
.uleb128 0x13
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x11
.uleb128 0x5
.byte 0x0
.uleb128 0x31
.uleb128 0x13
.uleb128 0x2
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x12
.uleb128 0x2e
.byte 0x1
.uleb128 0x1
.uleb128 0x13
.uleb128 0x3
.uleb128 0x8
.uleb128 0x34
.uleb128 0xc
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x13
.uleb128 0x5
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x2
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x14
.uleb128 0x2e
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x15
.uleb128 0x34
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x2
.uleb128 0xa
.byte 0x0
.byte 0x0
.byte 0x0
.section .debug_pubnames,"",@progbits
.long 0x3f
.value 0x2
.long .Ldebug_info0
.long 0x1f1
.long 0xd4
.string "main"
.long 0x111
.string "T5<int>::T5"
.long 0x135
.string "T5<int>::T5"
.long 0x1de
.string "t5i"
.long 0x0
.section .debug_aranges,"",@progbits
.long 0x2c
.value 0x2
.long .Ldebug_info0
.byte 0x4
.byte 0x0
.value 0x0
.value 0x0
.long .Ltext0
.long .Letext0-.Ltext0
.long .LFB7
.long .LFE7-.LFB7
.long .LFB9
.long .LFE9-.LFB9
.long 0x0
.long 0x0
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4 20030710 (experimental)"
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Broken .loc directive in GAS
2003-07-11 11:43 ` Alan Modra
@ 2003-07-11 15:16 ` Michal Ludvig
2003-07-11 22:36 ` Richard Henderson
2003-07-15 15:20 ` Michal Ludvig
1 sibling, 1 reply; 8+ messages in thread
From: Michal Ludvig @ 2003-07-11 15:16 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
Alan Modra told me that:
> I don't see any problem with current gcc-3.3 and mainline, and an older
> gcc-3.3. Current mainline gives:
Hmm, strange. I can see the same (broken) output on RedHat 9 with
gcc-3.2.2 and binutils 2.13.90.0.18 20030206 as well. I'll look on it
more on monday.
This comes from RedHat 9:
The File Name Table:
Entry Dir Time Size Name
1 1 0 0 temp.cc
Line Number Statements:
Extended opcode 2: set Address to 0x80483a6
Special opcode 13: advance Address by 0 to 0x80483a6 and Line by 8 to 9
Special opcode 47: advance Address by 3 to 0x80483a9 and Line by 0 to 9
Advance PC by 3 to 80483ac
Extended opcode 1: End of Sequence
Extended opcode 2: set Address to 0x80483a0
Special opcode 13: advance Address by 0 to 0x80483a0 and Line by 8 to 9
Special opcode 47: advance Address by 3 to 0x80483a3 and Line by 0 to 9
Advance PC by 3 to 80483a6
Extended opcode 1: End of Sequence
Extended opcode 2: set Address to 0x8048344
Advance Line by 16 to 17
[...]
Special opcode 89: advance Address by 6 to 0x804838c and Line by 0 to 13
Advance PC by 22 to 80483a2
Extended opcode 1: End of Sequence
Again - last sequence overlaps the beginning of the second one... Could
anyone with RedHat 9 confirm this please? Or is it only an annomaly of
this office?
Michal Ludvig
--
* SuSE CR, s.r.o * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Broken .loc directive in GAS
2003-07-11 15:16 ` Michal Ludvig
@ 2003-07-11 22:36 ` Richard Henderson
0 siblings, 0 replies; 8+ messages in thread
From: Richard Henderson @ 2003-07-11 22:36 UTC (permalink / raw)
To: Michal Ludvig; +Cc: Alan Modra, binutils
On Fri, Jul 11, 2003 at 05:16:46PM +0200, Michal Ludvig wrote:
> Hmm, strange. I can see the same (broken) output on RedHat 9 with
> gcc-3.2.2 and binutils 2.13.90.0.18 20030206 as well. I'll look on it
> more on monday.
I don't see it with
gcc-3.2.2-5 gcc version 3.2.2 20030222
binutils-2.13.90.0.18-9 GNU assembler 2.13.90 20030423
I.e. RH9 with current updates. Nor with cvs gcc+binutils.
r~
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Broken .loc directive in GAS
2003-07-11 11:43 ` Alan Modra
2003-07-11 15:16 ` Michal Ludvig
@ 2003-07-15 15:20 ` Michal Ludvig
2003-07-16 3:06 ` Alan Modra
1 sibling, 1 reply; 8+ messages in thread
From: Michal Ludvig @ 2003-07-15 15:20 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils, Richard Henderson
Alan Modra told me that:
> For reference, I've attached the -S output I get from your testcase.
> I suppose it's possible that ld is being confused by your crt*, libgcc
> or libc.
It's unlikely - I did some tests and it turns out that asm produced by
GCC from CVS (mainline and 3.3 release) give correct binary, but asm
generated by gcc-3.3-64 from SuSE 8.2 and by gcc-3.2.2-5 from RedHat 9
give give binaries with overlaps.
I have put some asm sources to: http://tmp.logix.cz/OffBy2/
along with a Makefile.
After you have built all four binaries run 'readelf -wl' on each of them
and compare results. You will see that temp-rh9 and temp-sl82 have
overlapping sequences in temp.cc entry.
At least I hope you'll see it! I tried to run it on RH8, SL8.2 and
Gentoo and everywhere got the same result (different addresses, but
overlapped by 2 bytes).
Is it a GCC or bug or a bug in a linker? Or does it still happening only
in my office?
Michal Ludvig
--
* SuSE CR, s.r.o * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Broken .loc directive in GAS
2003-07-15 15:20 ` Michal Ludvig
@ 2003-07-16 3:06 ` Alan Modra
0 siblings, 0 replies; 8+ messages in thread
From: Alan Modra @ 2003-07-16 3:06 UTC (permalink / raw)
To: Michal Ludvig; +Cc: binutils, Richard Henderson
On Tue, Jul 15, 2003 at 05:19:53PM +0200, Michal Ludvig wrote:
> and compare results. You will see that temp-rh9 and temp-sl82 have
> overlapping sequences in temp.cc entry.
> At least I hope you'll see it!
Yes, I see it. It's a gas bug, caused by a patch of mine.. :-(
This one: http://sources.redhat.com/ml/binutils/2001-11/msg00414.html
It's quite wrong to align sizes, of course. The thing is that addresses
aren't available at the stage dwarf2_finish runs.. I'm reverting the
patch, and applying a warning fix.
* dwarf2dbg.c (get_frag_fix): Revert 2001-11-15 change.
(generic_dwarf2_emit_offset): Don't define function when
TC__DWARF2_EMIT_OFFSET is defined.
Index: gas/dwarf2dbg.c
===================================================================
RCS file: /cvs/src/src/gas/dwarf2dbg.c,v
retrieving revision 1.63
diff -u -p -r1.63 dwarf2dbg.c
--- gas/dwarf2dbg.c 27 May 2003 16:00:04 -0000 1.63
+++ gas/dwarf2dbg.c 16 Jul 2003 03:02:12 -0000
@@ -52,10 +52,6 @@
# define DWARF2_ADDR_SIZE(bfd) (bfd_arch_bits_per_address (bfd) / 8);
#endif
-#ifndef TC_DWARF2_EMIT_OFFSET
-# define TC_DWARF2_EMIT_OFFSET generic_dwarf2_emit_offset
-#endif
-
#ifdef BFD_ASSEMBLER
#include "subsegs.h"
@@ -160,7 +156,6 @@ static struct dwarf2_line_info current;
/* The size of an address on the target. */
static unsigned int sizeof_address;
\f
-static void generic_dwarf2_emit_offset PARAMS((symbolS *, unsigned int));
static struct line_subseg *get_line_subseg PARAMS ((segT, subsegT));
static unsigned int get_filenum PARAMS ((const char *, unsigned int));
static struct frag *first_frag_for_seg PARAMS ((segT));
@@ -185,6 +180,10 @@ static void out_debug_aranges PARAMS ((s
static void out_debug_abbrev PARAMS ((segT));
static void out_debug_info PARAMS ((segT, segT, segT));
\f
+#ifndef TC_DWARF2_EMIT_OFFSET
+# define TC_DWARF2_EMIT_OFFSET generic_dwarf2_emit_offset
+static void generic_dwarf2_emit_offset PARAMS ((symbolS *, unsigned int));
+
/* Create an offset to .dwarf2_*. */
static void
@@ -199,6 +198,7 @@ generic_dwarf2_emit_offset (symbol, size
expr.X_add_number = 0;
emit_expr (&expr, size);
}
+#endif
/* Find or create an entry for SEG+SUBSEG in ALL_SEGS. */
@@ -632,11 +632,7 @@ get_frag_fix (frag)
on some subsegment chain. */
for (fr = frchain_root; fr; fr = fr->frch_next)
if (fr->frch_last == frag)
- {
- long align_mask = -1 << get_recorded_alignment (fr->frch_seg);
- return (((char *) obstack_next_free (&fr->frch_obstack)
- - frag->fr_literal) + ~align_mask) & align_mask;
- }
+ return (char *) obstack_next_free (&fr->frch_obstack) - frag->fr_literal;
abort ();
}
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-07-16 3:06 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-10 15:36 Broken .loc directive in GAS Michal Ludvig
2003-07-10 16:52 ` Richard Henderson
2003-07-11 6:27 ` Michal Ludvig
2003-07-11 11:43 ` Alan Modra
2003-07-11 15:16 ` Michal Ludvig
2003-07-11 22:36 ` Richard Henderson
2003-07-15 15:20 ` Michal Ludvig
2003-07-16 3:06 ` Alan Modra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).