From: Michal Ludvig <mludvig@suse.cz>
To: binutils@sources.redhat.com
Subject: Broken .loc directive in GAS
Date: Thu, 10 Jul 2003 15:36:00 -0000 [thread overview]
Message-ID: <3F0D87E8.2010003@suse.cz> (raw)
[-- 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;
}
next reply other threads:[~2003-07-10 15:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-10 15:36 Michal Ludvig [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F0D87E8.2010003@suse.cz \
--to=mludvig@suse.cz \
--cc=binutils@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).