This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/9509] Incorrect function end in DWARF2 .debug_line section
- From: "carlo at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Oct 2003 01:28:42 -0000
- Subject: [Bug debug/9509] Incorrect function end in DWARF2 .debug_line section
- References: <20030130171601.9509.carlo@alinoe.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9509
carlo at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |carlo at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
------- Additional Comments From carlo at gcc dot gnu dot org 2003-10-16 01:28 -------
This seems to be a bug in GNU as. I am investigating this now and will
close the PR once I am 100% sure it is in as and not gcc.
The version of 'objdump' that I have installed today (version GNU objdump
2.13.90.0.20 20030319) behaves slightly different, but 'as' version
2.13.90.0.20 20030319 still shows the same behaviour. It is just harder
to find though (I need my own 'libcwd' library to detect where the problem
is). For example:
(Running test application linked with libcwd:
BFD : Loading debug info from
/usr/src/GNU/builds-gcc/PR9509/PR9509-native/i686-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6...
<unfinished>
[...]
BFD : | 42c1b - 42c35;
/usr/src/GNU/builds-gcc/PR9509/PR9509-native/i686-pc-linux-gnu/libstdc++-v3/include/ext/pool_allocator.h:273
: "-DWARF symbol"..
BFD : | WARNING: Different start for same function (42c30 - 42c47;
/usr/src/GNU/builds-gcc/PR9509/PR9509-native/i686-pc-linux-gnu/libstdc++-v3/include/ext/pool_allocator.h:279
: "-DWARF symbol"..)!?
The ranges 42c1b - 42c35 and 42c30 - 42c47 overlap thus, and we
know that probably the end of the first range is wrong. The source
code at pool_allocator.h:273 till 279 reads:
return __result;
}
template<bool __threads, int __inst>
void*
__pool_alloc<__threads, __inst>::allocate(size_t __n)
{
So this is indeed the end of one function and the start of a next.
The first function (of which we now only see the end) starts at
line 245:
template<bool __threads, int __inst>
void*
__pool_alloc<__threads, __inst>::_S_refill(size_t __n)
{ <-- line 245
and from the same libcwd output we find that this corresponds with
the range:
BFD : | 42ba0 - 42bac;
/usr/src/GNU/builds-gcc/PR9509/PR9509-native/i686-pc-linux-gnu/libstdc++-v3/include/ext/poo
l_allocator.h:245 : "-DWARF symbol"..
where 42ba0 then must be the start of this function.
With 'nm' we then find:
nm
/usr/src/GNU/builds-gcc/PR9509/PR9509-native/i686-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6
| grep 42ba0
00042ba0 W _ZN9__gnu_cxx12__pool_allocILb1ELi0EE9_S_refillEj
and indeed, this is the correct function:
c++filt _ZN9__gnu_cxx12__pool_allocILb1ELi0EE9_S_refillEj
__gnu_cxx::__pool_alloc<(bool)1, (int)0>::_S_refill(unsigned)
Now we can look at the end of this function in the objdump, and
that start of the NEXT function, to find:
/usr/src/GNU/builds-gcc/PR9509/PR9509-native/i686-pc-linux-gnu/libstdc++-v3/include/ext/pool_allocator.h:273
42c1b: 8b 45 ec mov 0xffffffec(%ebp),%eax
42c1e: 83 c4 1c add $0x1c,%esp
42c21: 5b pop %ebx
42c22: 5e pop %esi
42c23: 5f pop %edi
42c24: 5d pop %ebp
42c25: c3 ret
42c26: 90 nop
42c27: 90 nop
42c28: 90 nop
42c29: 90 nop
42c2a: 90 nop
42c2b: 90 nop
42c2c: 90 nop
42c2d: 90 nop
42c2e: 90 nop
42c2f: 90 nop
00042c30 <_ZN9__gnu_cxx12__pool_allocILb1ELi0EE8allocateEj>:
_ZN9__gnu_cxx12__pool_allocILb1ELi0EE8allocateEj():
/usr/src/GNU/builds-gcc/PR9509/PR9509-native/i686-pc-linux-gnu/libstdc++-v3/include/ext/pool_allocator.h:279
42c30: 55 push %ebp
42c31: 89 e5 mov %esp,%ebp
42c33: 83 ec 38 sub $0x38,%esp
/usr/src/GNU/builds-gcc/PR9509/PR9509-native/i686-pc-linux-gnu/libstdc++-v3/include/ext/pool_allocator.h:273
42c36: 89 5d f4 mov %ebx,0xfffffff4(%ebp)
Where the last 'pool_allocator.h:273' is wrongly inserted as a result
of the end of the previous function being 'pushed in'.
However, the start of this function is now showed correctly.