Bug 172654 - bad dwarf location info for multi-register variables
bad dwarf location info for multi-register variables
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
Blocks: 168429 172383
  Show dependency treegraph
Reported: 2005-11-07 17:27 EST by Roland McGrath
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2006-0125
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-07 13:47:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Roland McGrath 2005-11-07 17:27:12 EST
+++ This bug was initially created as a clone of Bug #172652 +++

Description of problem:

Looks like wrong register numbers in location expressions for long long variable
(parameter).  Looking at multiple_reg_loc_descriptor, it seems like maybe it
assumes that contiguous GCC register numbers corresponds to contiguous DWARF
register numbers, which is not always so.

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
1. gcc -g -c -mregparm -O9 ll-debuginfo-loser.c
2. objdump -rd ll-debuginfo-loser.o; eu-readelf --debug-dump={info,loc}
3. Compare.
Actual results:

Expected results:

From 0..16, {ecx,edx} reg1 reg2
From 16..43, {ecx,ebx} reg1 reg3
From 43..4a, {esi,ebx} reg6 reg3

or something like that.  Obviously reg4 (%esp) should never be involved.

Additional info:

See Bug #172652 attachment for test case.  The real case is
fs/read_write.c:vfs_llseek in the RHEL4U2 kernel compile.
Comment 1 Jakub Jelinek 2005-11-08 09:38:56 EST

I hope this will make it into gcc-4_0-branch as well as gcc-3_4-branch, in
which case it would be fixed automatically given already acked #171239.
Comment 3 Roland McGrath 2005-11-27 17:55:12 EST
I am still seeing bad info for the bug #172652 attachment for test case. 
It's different from before, but still clearly wrong.

[    3f]  0000000000..0x00000035 [   0] reg2
                                  [   1] piece 4
                                  [   3] reg3
                                  [   4] piece 4
           0x00000035..0x0000003b [   0] reg3
                                  [   1] piece 4
                                  [   3] reg4
                                  [   4] piece 4
Comment 10 Red Hat Bugzilla 2006-03-07 13:47:53 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.