Bug 1930 - loc2c "should not happen" does
Summary: loc2c "should not happen" does
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-28 01:23 UTC by Frank Ch. Eigler
Modified: 2011-03-16 21:19 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed: 2005-12-02 23:00:08


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2005-11-28 01:23:10 UTC
See near line 570 in loc2c.c.  At least one of those FAIL's can be made to
trigger on both the PR 1868 kernel versions, using this script:

% stap -p2 -e 'probe kernel.syscall.* {}'

There are lots of other errors, but you'll see a dwarf_addrloclists or two in
there.  Could you diagnose whether this is a compiler, elfutils, or other problem?
Comment 1 Roland McGrath 2005-11-28 02:22:54 UTC
I reproduced this using:
./stap -v -p2 -e 'probe kernel.syscall.exit_group {}'
on 2.6.12-1.1381_FC3smp

A separate problem this displays is that systemtap is choosing a bogus probe PC
here--the PC off the end of the function.  That is an issue that was reported
for other cases on the mailing list, and needs a separate bug filed.

Correcting for that to select the same scopes systemtap gets, I reproduce it with:

./loc2c-test -k 0xc0124411 error_code

Here we see the trouble in the debug info:

[28a2cd]    subprogram
             sibling              [28a2f3]
             external
             name                 "sys_exit_group"
             decl_file            1
             decl_line            917
             prototyped
             low_pc               0xc0124411
             high_pc              0xc012441e
 [28a2e3]      formal_parameter
               name                 "error_code"
               decl_file            1
               decl_line            916
               type                 [27e6d4]
               location             2 byte block
                [   0] fbreg 4

Though fbreg is used, there is no frame_base attribute.
The code in question is a tail call:

c0124411 <sys_exit_group>:
c0124411:       0f b6 44 24 04          movzbl 0x4(%esp),%eax
c0124416:       c1 e0 08                shl    $0x8,%eax
c0124419:       e9 63 ff ff ff          jmp    c0124381 <do_group_exit>

There are definitely some gcc problems with the tail-call case.
Comment 2 Roland McGrath 2005-11-28 03:11:14 UTC
The frame_base attribute does appear in the 2.6.9-22.24.EL rebuild done by
gcc-3.4.4-3.  It appears this was fixed along with the other gcc problems.
This case should be checked on other kernel builds (FC4's gcc 4.0.x and
rawhide's gcc, for example) to be sure.
Comment 3 Roland McGrath 2005-12-02 23:00:08 UTC
See bug #1934 about the prologue detection issues in choosing the probe PC.
That is a separate problem that shows up in testing the cases here, and confuses
folks trying to test.  Will did some testing on a kernel built by the new
compiler on i686 and x86-64, and the results look good though the bug #1934
problem makes it harder to puzzle out.
Comment 4 Roland McGrath 2006-02-22 05:54:26 UTC
AFAIK this is about old GCC bugs that are gone now.
Please verify you no longer think there is an outstanding problem.
Comment 5 Frank Ch. Eigler 2006-04-27 16:45:40 UTC
ok now