* [Bug translator/13420] New: prologue detection fails for unoptimized 64bit cast-scope.exp testcase
@ 2011-11-21 12:22 mjw at redhat dot com
2011-11-21 12:44 ` [Bug translator/13420] " mjw at redhat dot com
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: mjw at redhat dot com @ 2011-11-21 12:22 UTC (permalink / raw)
To: systemtap
http://sourceware.org/bugzilla/show_bug.cgi?id=13420
Bug #: 13420
Summary: prologue detection fails for unoptimized 64bit
cast-scope.exp testcase
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: translator
AssignedTo: systemtap@sourceware.org
ReportedBy: mjw@redhat.com
Classification: Unclassified
cast-scope-m64 fails because prologue detection didn't pinpoint the right
location to pick up the arguments. Note that this only happens for 64-bit
builds without any optimization m64-O? and m32 are just fine.
The issue is that without optimization gcc will just put the incoming arguments
on the stack and then tell us through dwarf that they can be found on the stack
relative to the frame pointer:
[ 283b] subprogram
external (flag) Yes
name (strp) "length"
decl_file (data1) 1
decl_line (data1) 6
MIPS_linkage_name (strp) "_Z6lengthRKSs"
type (ref4) [ 70]
low_pc (addr) 0x00000000004007a4 <_Z6lengthRKSs>
high_pc (addr) 0x00000000004007bf <main>
frame_base (block1) [ 0] call_frame_cfa
sibling (ref4) [ 2870]
[ 2861] formal_parameter
name (string) "str"
decl_file (data1) 1
decl_line (data1) 6
type (ref4) [ 2870]
location (block1) [ 0] fbreg -24
But at the address where we probe the argument has not yet been moved on the
stack.
4007a4: 55 push %rbp
4007a5: 48 89 e5 mov %rsp,%rbp
4007a8: 48 83 ec 10 sub $0x10,%rsp
4007ac: 48 89 7d f8 mov %rdi,-0x8(%rbp)
4007b0: 90 nop
4007b1: 48 8b 45 f8 mov -0x8(%rbp),%rax
4007b5: 48 89 c7 mov %rax,%rdi
4007b8: e8 93 fe ff ff callq 0x400650
4007bd: c9 leaveq
4007be: c3 retq
searching for prologue of function 'length'
0x4007a4-0x4007bf@/home/mark/src/systemtap/testsuite/systemtap.base/cast-scope.cxx:6
checking line record
0x4007a4@/home/mark/src/systemtap/testsuite/systemtap.base/cast-scope.cxx:7
prologue found function 'length' (naked) = 0x4007a4
probe length@/home/mark/src/systemtap/testsuite/systemtap.base/cast-scope.cxx:6
process=/usr/local/build/systemtap-obj/testsuite/cast-scope-m64.exe
reloc=.absolute pc=0x4007a4
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug translator/13420] prologue detection fails for unoptimized 64bit cast-scope.exp testcase
2011-11-21 12:22 [Bug translator/13420] New: prologue detection fails for unoptimized 64bit cast-scope.exp testcase mjw at redhat dot com
@ 2011-11-21 12:44 ` mjw at redhat dot com
2011-11-29 17:19 ` mjw at redhat dot com
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: mjw at redhat dot com @ 2011-11-21 12:44 UTC (permalink / raw)
To: systemtap
http://sourceware.org/bugzilla/show_bug.cgi?id=13420
--- Comment #1 from Mark Wielaard <mjw at redhat dot com> 2011-11-21 12:43:12 UTC ---
BTW. GCC still doesn't emit real prologue markers in the line table.
See gcc/dwarf2out.c (dwarf2out_source_line):
/* ??? TODO: Elide duplicate line number entries. Traditionally,
the debugger has used the second (possibly duplicate) line number
at the beginning of the function to mark the end of the prologue.
We could eliminate any other duplicates within the function. For
Dwarf3, we ought to include the DW_LNS_set_prologue_end mark in
that second line number entry. */
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug translator/13420] prologue detection fails for unoptimized 64bit cast-scope.exp testcase
2011-11-21 12:22 [Bug translator/13420] New: prologue detection fails for unoptimized 64bit cast-scope.exp testcase mjw at redhat dot com
2011-11-21 12:44 ` [Bug translator/13420] " mjw at redhat dot com
@ 2011-11-29 17:19 ` mjw at redhat dot com
2011-11-30 16:36 ` mjw at redhat dot com
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: mjw at redhat dot com @ 2011-11-29 17:19 UTC (permalink / raw)
To: systemtap
http://sourceware.org/bugzilla/show_bug.cgi?id=13420
--- Comment #2 from Mark Wielaard <mjw at redhat dot com> 2011-11-29 17:11:32 UTC ---
Note that on powerpc both unoptimized -m32 and -m64 fail because of this issue.
Both have been kfailed.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug translator/13420] prologue detection fails for unoptimized 64bit cast-scope.exp testcase
2011-11-21 12:22 [Bug translator/13420] New: prologue detection fails for unoptimized 64bit cast-scope.exp testcase mjw at redhat dot com
2011-11-21 12:44 ` [Bug translator/13420] " mjw at redhat dot com
2011-11-29 17:19 ` mjw at redhat dot com
@ 2011-11-30 16:36 ` mjw at redhat dot com
2013-12-26 12:54 ` [Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code fche at redhat dot com
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: mjw at redhat dot com @ 2011-11-30 16:36 UTC (permalink / raw)
To: systemtap
http://sourceware.org/bugzilla/show_bug.cgi?id=13420
--- Comment #3 from Mark Wielaard <mjw at redhat dot com> 2011-11-30 16:35:14 UTC ---
Filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358
But note that even if we get location information it will likely say "not
available" at the start of the function where we place the probe. So then we
have to still do something (have a better prologue searcher?)
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code
2011-11-21 12:22 [Bug translator/13420] New: prologue detection fails for unoptimized 64bit cast-scope.exp testcase mjw at redhat dot com
` (2 preceding siblings ...)
2011-11-30 16:36 ` mjw at redhat dot com
@ 2013-12-26 12:54 ` fche at redhat dot com
2013-12-26 13:04 ` fche at redhat dot com
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: fche at redhat dot com @ 2013-12-26 12:54 UTC (permalink / raw)
To: systemtap
https://sourceware.org/bugzilla/show_bug.cgi?id=13420
Frank Ch. Eigler <fche at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fche at redhat dot com
Summary|prologue detection fails |prologue detection fails
|for unoptimized 64bit |for function parameters in
|cast-scope.exp testcase |unoptimized (-g only, no
| |-O) code
--- Comment #4 from Frank Ch. Eigler <fche at redhat dot com> ---
We should attempt to work around the gcc bug in systemtap, but will need
to improve the prologue-searching heuristics already in effect.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code
2011-11-21 12:22 [Bug translator/13420] New: prologue detection fails for unoptimized 64bit cast-scope.exp testcase mjw at redhat dot com
` (3 preceding siblings ...)
2013-12-26 12:54 ` [Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code fche at redhat dot com
@ 2013-12-26 13:04 ` fche at redhat dot com
2014-02-12 16:42 ` jlebon at redhat dot com
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: fche at redhat dot com @ 2013-12-26 13:04 UTC (permalink / raw)
To: systemtap
https://sourceware.org/bugzilla/show_bug.cgi?id=13420
--- Comment #5 from Frank Ch. Eigler <fche at redhat dot com> ---
By the way, the .debug_line pattern for a toy program that demonstrates this:
% cat ~/foo.c
int foo (int j)
{
printf("%d", j);
}
int main ()
{
int x = 5;
foo (x);
}
% gcc -g -o foo foo.c
% objdump -drs foo
[...]
0000000000400530 <foo>:
400530: 55 push %rbp
400531: 48 89 e5 mov %rsp,%rbp
400534: 48 83 ec 10 sub $0x10,%rsp
400538: 89 7d fc mov %edi,-0x4(%rbp)
40053b: 8b 45 fc mov -0x4(%rbp),%eax
40053e: 89 c6 mov %eax,%esi
400540: bf 00 06 40 00 mov $0x400600,%edi
400545: b8 00 00 00 00 mov $0x0,%eax
40054a: e8 c1 fe ff ff callq 400410 <printf@plt>
40054f: c9 leaveq
400550: c3 retq
% readelf -w foo
<1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e> DW_AT_external : 1
<2e> DW_AT_name : foo
<32> DW_AT_decl_file : 1
<33> DW_AT_decl_line : 1
<34> DW_AT_prototyped : 1
<34> DW_AT_type : <0x6d>
<38> DW_AT_low_pc : 0x400530
<40> DW_AT_high_pc : 0x21
<48> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<4a> DW_AT_GNU_all_tail_call_sites: 1
<4a> DW_AT_sibling : <0x6d>
<2><4e>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<4f> DW_AT_name : j
<51> DW_AT_decl_file : 1
<52> DW_AT_decl_line : 1
<53> DW_AT_type : <0x6d>
<57> DW_AT_location : 2 byte block: 91 6c (DW_OP_fbreg: -20)
[...]
Line Number Statements:
Extended opcode 2: set Address to 0x400530
Special opcode 6: advance Address by 0 to 0x400530 and Line by 1 to 2
Special opcode 160: advance Address by 11 to 0x40053b and Line by 1 to 3
Advance PC by constant 17 to 0x40054c
Special opcode 48: advance Address by 3 to 0x40054f and Line by 1 to 4
Special opcode 36: advance Address by 2 to 0x400551 and Line by 3 to 7
It is at instruction 0x40053b at which the location becomes accurate
(after %edi, the incoming parameter, is saved to the stack). stap's -P
algorithm stops looking at the special-opcode-6 part, where the line number
was incremented from 1 to 2, but the address wasn't changed.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code
2011-11-21 12:22 [Bug translator/13420] New: prologue detection fails for unoptimized 64bit cast-scope.exp testcase mjw at redhat dot com
` (4 preceding siblings ...)
2013-12-26 13:04 ` fche at redhat dot com
@ 2014-02-12 16:42 ` jlebon at redhat dot com
2014-02-27 19:56 ` jlebon at redhat dot com
2014-02-28 20:09 ` jlebon at redhat dot com
7 siblings, 0 replies; 9+ messages in thread
From: jlebon at redhat dot com @ 2014-02-12 16:42 UTC (permalink / raw)
To: systemtap
https://sourceware.org/bugzilla/show_bug.cgi?id=13420
Jonathan Lebon <jlebon at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jlebon at redhat dot com
--- Comment #6 from Jonathan Lebon <jlebon at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #4)
> We should attempt to work around the gcc bug in systemtap, but will need
> to improve the prologue-searching heuristics already in effect.
One of the issues here is that our current heuristics rely on srclines to guess
the prologue end. This can cause problems, because line numbers are completely
independent of the prologue. For example, the following examples will cause
different behaviours when run through resolve_prologue_endings(), even though
the prologue ends at the same address in all cases (all variations of the
example given in comment 5):
---------------
// All on different lines
int foo (int j)
{
printf("%d", j);
}
// Result: thinks there's no prologue (naked), because the line advance to
// '{' is for the same addr (as we saw in comment 5). As a result, we get
// bad j values
// Opening brace on same line as decl
int foo (int j) {
printf("%d", j);
}
// Result: correctly finds the prologue end because the first line advance
// occurs at the same time as the addr change
// All on same line
int foo (int j) { printf("%d", j); }
// Result: correctly finds the prologue end (for the wrong reasons). It goes
// through the line records, and seeing no line advances, runs off the
// function's highpc, so then goes back one step. What saves us here is the
// 0-line advance GCC adds to mark the end of the prologue. We normally ignore
// it since the lineno doesn't change. (The 0-line advance is also mentioned
// here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358#c1).
// Split lines
int foo (int j) { printf("%d", j);
printf("%d", j*2);
}
// Result: thinks the prologue end is at 0x4005f4, which actually corresponds
to
// the addr of the second printf call. Happens because that's where the first
// line advance occurs.
---------------
I think part of the solution here is to take advantage of the 0-line advance
when it is present (which I think only occurs when the prologue end doesn't
correspond to a line advance). This might mean simply always skipping the first
line record, regardless of actual line advances.
I'm also looking into GDB's way of handling the problem. It seems like there is
also arch-specific code to find specific opcodes in the prologue if line number
information fails to provide a clear answer (see e.g. amd64_analyze_prologue():
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/amd64-tdep.c;h=72d748e;hb=HEAD#l2129).
Depending on how often/likely lineno info can fail, we might not need to go
that far.
To be continued...
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code
2011-11-21 12:22 [Bug translator/13420] New: prologue detection fails for unoptimized 64bit cast-scope.exp testcase mjw at redhat dot com
` (5 preceding siblings ...)
2014-02-12 16:42 ` jlebon at redhat dot com
@ 2014-02-27 19:56 ` jlebon at redhat dot com
2014-02-28 20:09 ` jlebon at redhat dot com
7 siblings, 0 replies; 9+ messages in thread
From: jlebon at redhat dot com @ 2014-02-27 19:56 UTC (permalink / raw)
To: systemtap
https://sourceware.org/bugzilla/show_bug.cgi?id=13420
Jonathan Lebon <jlebon at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #7 from Jonathan Lebon <jlebon at redhat dot com> ---
I've updated the prologue searching algorithm so that we now pick up both
prologue_end markers (which clang emits) and 0-line advances (which GCC emits).
All the issues in comment 6 are now resolved, as well as the original
cast-scope testcase.
I also tested and tweaked it to work on older kernels/gccs (or at least to not
be less wrong than we were before). In some cases, we do even better there as
well!
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code
2011-11-21 12:22 [Bug translator/13420] New: prologue detection fails for unoptimized 64bit cast-scope.exp testcase mjw at redhat dot com
` (6 preceding siblings ...)
2014-02-27 19:56 ` jlebon at redhat dot com
@ 2014-02-28 20:09 ` jlebon at redhat dot com
7 siblings, 0 replies; 9+ messages in thread
From: jlebon at redhat dot com @ 2014-02-28 20:09 UTC (permalink / raw)
To: systemtap
https://sourceware.org/bugzilla/show_bug.cgi?id=13420
--- Comment #8 from Jonathan Lebon <jlebon at redhat dot com> ---
I forgot to mark down the related commits here: 02a15be and 7db8343 (and
previous).
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-02-28 20:09 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-21 12:22 [Bug translator/13420] New: prologue detection fails for unoptimized 64bit cast-scope.exp testcase mjw at redhat dot com
2011-11-21 12:44 ` [Bug translator/13420] " mjw at redhat dot com
2011-11-29 17:19 ` mjw at redhat dot com
2011-11-30 16:36 ` mjw at redhat dot com
2013-12-26 12:54 ` [Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code fche at redhat dot com
2013-12-26 13:04 ` fche at redhat dot com
2014-02-12 16:42 ` jlebon at redhat dot com
2014-02-27 19:56 ` jlebon at redhat dot com
2014-02-28 20:09 ` jlebon at redhat dot com
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).