616050 – Missing or partial location expressions

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 616050 - Missing or partial location expressions

Summary: Missing or partial location expressions

Keywords:
Status:	CLOSED CURRENTRELEASE
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	gcc
Sub Component:
Version:	6.0
Hardware:	All
OS:	Linux
Priority:	low
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Jakub Jelinek
QA Contact:	Michal Nowak
Docs Contact:
URL:
Whiteboard:
Depends On:	613822 613824
Blocks:	653998
TreeView+	depends on / blocked

Reported:	2010-07-19 14:30 UTC by Mark Wielaard
Modified:	2013-03-08 02:11 UTC (History)
CC List:	14 users (show)
Fixed In Version:	gcc-4.4.4-13.el6
Doc Type:	Bug Fix
Doc Text:
Clone Of:	613824
Clones:	653998 (view as bug list)
Environment:
Last Closed:	2010-11-10 20:25:06 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)
preprocessed sources (373.92 KB, application/x-bzip) 2010-07-19 15:06 UTC, Mark Wielaard	no flags	Details
gcc44-rh616050-arg8.patch (951 bytes, patch) 2010-07-20 08:50 UTC, Jakub Jelinek	no flags	Details \| Diff
gcc44-rh616050-arg2.patch (674 bytes, patch) 2010-07-20 09:34 UTC, Jakub Jelinek	no flags	Details \| Diff
View All

Description Mark Wielaard 2010-07-19 14:30:10 UTC

Part of the problem of bug #613824 is missing or partial location expressions produced by gcc. Opening this new bug to track that.

+++ This bug was initially created as a clone of Bug #613824 +++

+++ This bug was initially created as a clone of Bug #613822 +++

Description of problem:

When attempting to use some of the variable avialable in the hotspot tapset found that some of the arguments were not available.

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

systemtap-1.2-1.fc13.x86_64
java-1.6.0-openjdk-1.6.0.0-41.b18.fc13.x86_64
java-1.6.0-openjdk-devel-1.6.0.0-41.b18.fc13.x86_64
java-1.6.0-openjdk-debuginfo-1.6.0.0-41.b18.fc13.x86_64


How reproducible:

everytime

Steps to Reproduce:
1. Install  systemtap java-1.6.0-openjdk  java-1.6.0-openjdk-devel    java-1.6.0-openjdk-debuginfo
2. stap -L 'hotspot.*' > /dev/null
3. See the messages in the "actual results" section
  
Actual results:

semantic error: not accessible at this address (0x515136): identifier '$arg2' at /usr/share/systemtap/tapset/x86_64/hotspot.stp:438:32
        source:   class = user_string_n($arg1, $arg2);
                                               ^
semantic error: not accessible at this address (0x515136): identifier '$arg6' at :440:30
        source:   sig = user_string_n($arg5, $arg6);
                                             ^
semantic error: failed to retrieve location attribute for local 'arg8' (dieoffset: 0x3c5adc0): identifier '$arg8' at :442:10
        source:   size = $arg8;
                         ^
semantic error: not accessible at this address (0x5170b7): identifier '$arg2' at :456:32
        source:   class = user_string_n($arg1, $arg2);
                    

Expected results:

All the probe point arguments available in the hotspot tapset should be available. There shouldn't be any "semantic error" messages.


Additional info:

The probe hotspot.object_alloc has:

 size = $arg3;

that should be $arg4 for size according to http://java.sun.com/javase/6/docs/technotes/guides/vm/dtrace.html. However, when this is corrected get:

semantic error: not accessible at this address (0x59d460): identifier '$arg4' at :117:10
        source:   size = $arg4;
                         ^

--- Additional comment from wcohen on 2010-07-12 17:37:12 EDT ---

See a similar problem of missing $arg variables for hotspot probe points on RHEL-6 with the following rpms:

systemtap-1.2-9.el6.x86_64
java-1.6.0-openjdk-1.6.0.0-1.20.b17.el6.x86_64
java-1.6.0-openjdk-devel-1.6.0.0-1.20.b17.el6.x86_64
java-1.6.0-openjdk-debuginfo-1.6.0.0-1.20.b17.el6.x86_64

$ stap -L 'hotspot.*' > /dev/nullsemantic error: not accessible at this address (0x515036): identifier '$arg2' at /usr/share/systemtap/tapset/x86_64/hotspot.stp:438:32
        source:   class = user_string_n($arg1, $arg2);
                                               ^
semantic error: failed to retrieve location attribute for local 'arg8' (dieoffset: 0x3c5b7ce): identifier '$arg8' at :442:10
        source:   size = $arg8;
                         ^
semantic error: not accessible at this address (0x29156a): identifier '$arg4' at :236:32
        source:   class = user_string_n($arg3, $arg4);
                                               ^
semantic error: not accessible at this address (0x29156a): identifier '$arg6' at :237:33
        source:   method = user_string_n($arg5, $arg6);
                                                ^
semantic error: not accessible at this address (0x29183f): identifier '$arg4' at :254:32
        source:   class = user_string_n($arg3, $arg4);
                                               ^
semantic error: not accessible at this address (0x29183f): identifier '$arg6' at :255:33
        source:   method = user_string_n($arg5, $arg6);
                                                ^
semantic error: not accessible at this address (0x29183f): identifier '$arg8' at :256:30
        source:   sig = user_string_n($arg7, $arg8);
                                             ^
semantic error: not accessible at this address (0x59d4b0): identifier '$arg4' at :117:10
        source:   size = $arg4;
                         ^

--- Additional comment from pm-rhel on 2010-07-12 17:41:08 EDT ---

Since this issue was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from pm-rhel on 2010-07-15 10:27:34 EDT ---

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

--- Additional comment from mjw on 2010-07-19 06:27:35 EDT ---

The hotspot.object_alloc typo has a patch upstream and posted to the fedora bug report.

The "semantic error: failed to retrieve location attribute for local 'arg8'
(dieoffset: 0x3c5b7ce)" is because gcc did indeed did not output one in that case:

$ readelf --debug-dump=info /usr/lib/debug/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so.debug
 <4><3c5b7ce>: Abbrev Number: 171 (DW_TAG_variable)
    <3c5b7d0>   DW_AT_name        : (indirect string, offset: 0x11e0b9): arg8   
    <3c5b7d4>   DW_AT_decl_file   : 4   
    <3c5b7d5>   DW_AT_decl_line   : 1374        
    <3c5b7d7>   DW_AT_type        : <0x3c2e616> 

No DW_AT_location.

The not $argN is not accessible at this address errors are harder to spot where they come from. It should be noted that eu-readelf doesn't seem to like the .debug_loc section. Although readelf seems to parse it (with some warnings).

The error comes from dwarf_getlocation_addr () returning zero (which has the helpful comment /* Shouldn't happen.  */).

See for example through loc2c-test:

$ ./loc2c-test -e /usr/lib/debug/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so.debug 0x515036

        [3c5b6db] post_compiled_method_load_event (0x2e): 0x514fc0 (/usr/src/debug/icedtea6-1.7.3/openjdk/hotspot/src/share/vm/code/nmethod.cpp:1371) .. 0x515068 (/usr/src/debug/icedtea6-1.7.3/openjdk/hotspot/src/share/vm/code/nmethod.cpp:1384)
            this                          [3c5b6f7]     nmethod* const
            [3c5b706] <unnamed> (0xb)
                moop                          [3c5b70c] methodOop
                [3c5b745] <unnamed> (0xb): 0x514fdb (/usr/src/debug/icedtea6-1.7.3/openjdk/hotspot/src/share/vm/code/nmethod.cpp:1374) .. 0x515037 (/usr/src/debug/icedtea6-1.7.3/openjdk/hotspot/src/share/vm/code/nmethod.cpp:1383)
                    arg1                          [3c5b757]     jbyte*
                    arg2                          [3c5b768]     int
                    arg3                          [3c5b779]     jbyte*
                    arg4                          [3c5b78a]     int
                    arg5                          [3c5b79b]     jbyte*
                    arg6                          [3c5b7ac]     int
                    arg7                          [3c5b7bd]     address
                    arg8                          [3c5b7ce]     int

$ eu-readelf -N --debug-dump=info /usr/lib/debug/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so.debug

 [3c5b768]          variable
                   name                 (strp) "arg2"
                   decl_file            (data1) 4
                   decl_line            (data2) 1374
                   type                 (ref4) [3c2e616]
                   location             (data4) location list [ee657c]

$ readelf --debug-dump=loc /usr/lib/debug/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so.debug

    00ee657c 0000000000514fee 0000000000515027 (DW_OP_breg0: 16)
    00ee657c <End of list>

Will investigate further.

--- Additional comment from mjw on 2010-07-19 07:40:40 EDT ---

(In reply to comment #4)
> See for example through loc2c-test:
> 
> $ ./loc2c-test -e
> /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
> 0x515036
> > [...]
> $ eu-readelf -N --debug-dump=info
> /usr/lib/debug/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so.debug
> 
>  [3c5b768]          variable
>                    name                 (strp) "arg2"
>                    decl_file            (data1) 4
>                    decl_line            (data2) 1374
>                    type                 (ref4) [3c2e616]
>                    location             (data4) location list [ee657c]
> 
> $ readelf --debug-dump=loc
> /usr/lib/debug/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so.debug
> 
>     00ee657c 0000000000514fee 0000000000515027 (DW_OP_breg0: 16)
>     00ee657c <End of list>
> 
> Will investigate further.    

That actually tells the story. We are looking for arg2 at address 0x515036, but we only got a location description for the addresses 0x514fee till 0x515027. So we are looking just beyond what the compiler can give us.

If we look at the other variables (arg1 and arg3) we see they do have location descriptions that are in scope for address 0x515036:

 [3c5b757]          variable
                   name                 (strp) "arg1"
                   decl_file            (data1) 4
                   decl_line            (data2) 1374
                   type                 (ref4) [3c2e9d3]
                   location             (data4) location list [ee651c]

    00ee651c 0000000000514fe9 0000000000514fed (DW_OP_breg0: 18; DW_OP_stack_value)
    00ee651c 0000000000514fed 0000000000515023 (DW_OP_breg13: 18; DW_OP_stack_value)
    00ee651c 0000000000515023 000000000051504f (DW_OP_reg13)
    00ee651c 0000000000515051 0000000000515067 (DW_OP_reg13)
    00ee651c <End of list>

 [3c5b779]          variable
                   name                 (strp) "arg3"
                   decl_file            (data1) 4
                   decl_line            (data2) 1374
                   type                 (ref4) [3c2e9d3]
                   location             (data4) location list [ee65a0]

    00ee65a0 0000000000515008 000000000051502b (DW_OP_breg4: 18; DW_OP_stack_value)
    00ee65a0 000000000051502b 000000000051505b (DW_OP_reg5)
    00ee65a0 <End of list>

--- Additional comment from mjw on 2010-07-19 10:08:51 EDT ---

The preprocessed (-E) method this happens in looks like:

void nmethod::post_compiled_method_load_event() {

  methodOop moop = method();
  do { __typeof__(((moop->klass_name()->bytes()))) arg1 = (moop->klass_name()->bytes()); __typeof__(((moop->klass_name()->utf8_length()))) arg2 = (moop->klass_name()->utf8_length()); __typeof__(((moop->name()->bytes()))) arg3 = (moop->name()->bytes()); __typeof__(((moop->name()->utf8_length()))) arg4 = (moop->name()->utf8_length()); __typeof__(((moop->signature()->bytes()))) arg5 = (moop->signature()->bytes()); __typeof__(((moop->signature()->utf8_length()))) arg6 = (moop->signature()->utf8_length()); __typeof__(((code_begin()))) arg7 = (code_begin()); __typeof__(((code_size()))) arg8 = (code_size()); ; __asm__ volatile (".section .probes," "\"aw\"" "\n" "\t.balign 8\n" "1:\n\t.asciz " "\"compiled__method__load\"" "\n" "\t.balign 4\n" "\t.int " "0x31425250" "\n" "\t.balign 8\n" "\t.quad " "1b\n" "\t.balign 8\n" "\t.quad " "2f" "\n" "\t.int 0\n" "\t.previous\n"); __asm__ volatile ("2:\n" "\tnop " "/* %0 %1 %2 %3 %4 %5 %6 %7 */" :: "g"(arg1), "g"(arg2), "g"(arg3), "g"(arg4), "g"(arg5), "g"(arg6), "g"(arg7), "g"(arg8)); } while (0)






                                ;

  if (JvmtiExport::should_post_compiled_method_load()) {
    JvmtiExport::post_compiled_method_load(this);
  }
}

--- Additional comment from mjw on 2010-07-19 10:13:44 EDT ---

Which generates the following assembly (-S):

.globl _ZN7nmethod31post_compiled_method_load_eventEv
        .type   _ZN7nmethod31post_compiled_method_load_eventEv, @function
_ZN7nmethod31post_compiled_method_load_eventEv:
.LFB14506:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.cpp:1429
        .loc 5 1429 0
        .cfi_startproc
.LVL460:
        # basic block 2
        pushq   %rbp    #
        .cfi_def_cfa_offset 16
        movq    %rsp, %rbp      #,
        .cfi_offset 6, -16
        .cfi_def_cfa_register 6
        movq    %rbx, -24(%rbp) #,
        movq    %r13, -8(%rbp)  #,
        movq    %rdi, %rbx      # this, this
        .cfi_offset 13, -24
        .cfi_offset 3, -40
.LVL461:
        movq    %r12, -16(%rbp) #,
        subq    $32, %rsp       #,
.LBB4617:
.LBB4618:
.LBB4619:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.hpp:321
        .loc 4 321 0
        movq    72(%rdi), %r12  # <variable>._method, moop
        .cfi_offset 12, -32
.LVL462:
.LBE4619:
.LBE4618:
.LBB4620:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.cpp:1432
        .loc 5 1432 0
        movq    %r12, %rdi      # moop,
.LVL463:
        call    _ZNK13methodOopDesc10klass_nameEv@PLT   #
.LVL464:
        movq    %r12, %rdi      # moop,
        movq    %rax, %r13      #, D.157337
.LVL465:
        call    _ZNK13methodOopDesc10klass_nameEv@PLT   #
.LVL466:
.LBB4621:
.LBB4622:
.LBB4634:
.LBB4635:
.LBB4636:
        .file 24 "/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/oops/methodOop.hpp"
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/oops/methodOop.hpp:137
        .loc 24 137 0
        movq    16(%r12), %rcx  # <variable>._constMethod, D.165475
.LVL467:
.LBE4636:
.LBE4635:
.LBE4634:
.LBB4623:
.LBB4624:
.LBB4625:
.LBB4626:
.LBB4627:
.LBB4628:
        .file 25 "/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/oops/constantPoolOop.hpp"
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/oops/constantPoolOop.hpp:73
        .loc 25 73 0
        movq    24(%r12), %rdx  # <variable>._constants, <variable>._constants
.LBE4628:
.LBE4627:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/oops/constantPoolOop.hpp:297
        .loc 25 297 0
        movzwl  64(%rcx), %esi  # <variable>._name_index, <variable>._name_index
.LBE4626:
.LBE4625:
.LBE4624:
.LBE4623:
.LBE4622:
.LBE4621:
.LBB4639:
.LBB4640:
.LBB4641:
.LBB4642:
.LBB4643:
        movzwl  66(%rcx), %ecx  # <variable>._signature_index, <variable>._signature_index
.LBE4643:
.LBE4642:
.LBE4641:
.LBE4640:
.LBE4639:
.LBB4646:
.LBB4638:
.LBB4637:
.LBB4633:
.LBB4632:
.LBB4631:
.LBB4630:
.LBB4629:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/oops/constantPoolOop.hpp:73
        .loc 25 73 0
        addq    $56, %rdx       #, D.165473
.LBE4629:
.LBE4630:
.LBE4631:
.LBE4632:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/oops/constantPoolOop.hpp:297
        .loc 25 297 0
        movq    (%rdx,%rsi,8), %rsi     #* D.165473, D.165466
.LVL468:
.LBE4633:
.LBE4637:
.LBE4638:
.LBE4646:
.LBB4647:
.LBB4645:
.LBB4644:
        movq    (%rdx,%rcx,8), %rcx     #* D.165473, D.165511
.LVL469:
.LBE4644:
.LBE4645:
.LBE4647:
.LBB4648:
.LBB4649:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.hpp:340
        .loc 4 340 0
        movq    184(%rbx), %rdx # <variable>._entry_point, arg7
.LVL470:
.LBE4649:
.LBE4648:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.cpp:1432
        .loc 5 1432 0
#APP
# 1432 "/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.cpp" 1
        .section .probes,"aw"
        .balign 8
1:
        .asciz "compiled__method__load"
        .balign 4
        .int 0x31425250
        .balign 8
        .quad 1b
        .balign 8
        .quad 2f
        .int 0
        .previous

# 0 "" 2
#NO_APP
.LBB4650:
.LBB4651:
.LBB4652:
.LBB4653:
        movslq  140(%rbx), %r9  # <variable>._stub_offset, <variable>._stub_offset
.LBE4653:
.LBE4652:
.LBE4651:
.LBE4650:
        leaq    18(%rsi), %rdi  #, tmp74
        leaq    18(%rcx), %r8   #, tmp76
        addq    $18, %r13       #, tmp72
.LVL471:
.LBB4657:
.LBB4658:
        movzwl  16(%rax), %eax  # <variable>._length, <variable>._length
.LVL472:
.LBE4658:
.LBE4657:
.LBB4659:
.LBB4660:
        movzwl  16(%rsi), %esi  # <variable>._length, <variable>._length
.LVL473:
.LBE4660:
.LBE4659:
.LBB4661:
.LBB4662:
        movzwl  16(%rcx), %ecx  # <variable>._length, <variable>._length
.LVL474:
.LBE4662:
.LBE4661:
.LBB4663:
.LBB4656:
.LBB4655:
.LBB4654:
        leaq    (%rbx,%r9), %r9 #, tmp80
.LBE4654:
.LBE4655:
        subl    %edx, %r9d      # arg7, tmp81
.LBE4656:
.LBE4663:
#APP
# 1432 "/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.cpp" 1
        2:
        nop /* %r13 %eax %rdi %esi %r8 %ecx %rdx %r9d */        # tmp72, <variable>._length, tmp74, <variable>._length, tmp76, <variable>._length, arg7, tmp81
# 0 "" 2
#NO_APP
.LBE4620:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.cpp:1441
        .loc 5 1441 0
        movq    _ZN11JvmtiExport33_should_post_compiled_method_loadE@GOTPCREL(%rip), %rax       #, tmp82
        cmpb    $0, (%rax)      # _should_post_compiled_method_load
        jne     .L341   #,
        # basic block 3
.LBE4617:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.cpp:1444
        .loc 5 1444 0
        movq    -24(%rbp), %rbx #,
.LVL475:
        movq    -16(%rbp), %r12 #,
.LVL476:
        movq    -8(%rbp), %r13  #,
.LVL477:
        leave
        .cfi_remember_state
        .cfi_def_cfa 7, 8
        ret
.LVL478:
        .p2align 4,,10
        .p2align 3
.L341:
        # basic block 4
        .cfi_restore_state
.LBB4664:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.cpp:1442
        .loc 5 1442 0
        movq    %rbx, %rdi      # this,
.LVL479:
.LBE4664:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.cpp:1444
        .loc 5 1444 0
        movq    -16(%rbp), %r12 #,
.LVL480:
        movq    -24(%rbp), %rbx #,
.LVL481:
        movq    -8(%rbp), %r13  #,
.LVL482:
        leave
        .cfi_def_cfa 7, 8
.LBB4665:
        # /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.cpp:1442
        .loc 5 1442 0
        jmp     _ZN11JvmtiExport25post_compiled_method_loadEP7nmethod@PLT       #
.LBE4665:
        .cfi_endproc
.LFE14506:
        .size   _ZN7nmethod31post_compiled_method_load_eventEv, .-_ZN7nmethod31post_compiled_method_load_eventEv

Comment 2 RHEL Program Management 2010-07-19 14:58:08 UTC

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 3 Mark Wielaard 2010-07-19 15:06:13 UTC

Created attachment 432914 [details]
preprocessed sources

Produced with:

g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. -I../generated/adfiles -I../generated/jvmtifiles -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/asm -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/ci -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/classfile -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/compiler -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/gc_implementation -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/gc_implementation/parNew -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/gc_implementation/g1 -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/gc_implementation/shared -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/gc_interface -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/interpreter -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/libadt -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/memory -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/oops -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/opto -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/prims -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/runtime -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/services -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/shark -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/utilities -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/cpu/x86/vm -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/os/linux/vm -I/usr/local/build/icedtea6-obj/openjdk/hotspot/src/os_cpu/linux_x86/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"17.0-b16\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mark\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DJRE_RELEASE_VERSION="\"1.6.0_20-b20\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDERIVATIVE_ID="\"IcedTea6 1.9pre+rb4455c6c313f\"" -DDISTRIBUTION_ID="\"Built on Red Hat Enterprise Linux Workstation release 6.0 Beta (Santiago) (Mon Jul 19 10:49:35 CEST 2010)\"" -DCOMPILER2 -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -m64 -pipe -g -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wpointer-arith -Wsign-compare    -DDTRACE_ENABLED -c -o nmethod.E -E -dA -fverbose-asm /usr/local/build/icedtea6-obj/openjdk/hotspot/src/share/vm/code/nmethod.cpp

Comment 4 Jakub Jelinek 2010-07-20 08:50:46 UTC

Created attachment 433107 [details]
gcc44-rh616050-arg8.patch

The missing arg8 location can be fixed by attached patch, the expressions are just too large and trigger the maximum depth 5 check.  This is something I have in my entry value patchset for months.
Now that we don't blindly create RTL during expansion, but first test whether it can actually lead to useful location, I think it is not so pricey to allow larger limit, perhaps we could go even to 10 or so.

I see the arg2 issue too (this one in all 3 spots), looking into that now.

Comment 5 Jakub Jelinek 2010-07-20 09:34:57 UTC

Created attachment 433112 [details]
gcc44-rh616050-arg2.patch

Fix for the other problem.  We were using ZERO_EXTEND vs. SIGN_EXTEND incorrectly in DEBUG_INSNs - for DEBUG argn22 => (int) D.157339D.157339->_length
where _length field is unsigned short we were using SIGN_EXTEND instead of ZERO_EXTEND in DEBUG_INSN, while the actual code was of course using ZERO_EXTEND and thus when the memory value was loaded and zero extended into a register after the DEBUG_INSN, we concluded the value is no longer available.

Of course, even for mismatching ZERO_EXTEND vs. SIGN_EXTEND when it is really needed in some code we could do something, but it might be expensive (for values containing outermost ZERO_EXTEND or SIGN_EXTEND we could also record the inner VALUE lives in inner part of some register).

Anyway, this patch should be sufficient now.

Comment 6 Jakub Jelinek 2010-07-20 14:23:57 UTC

Both fixes now approved and committed upstream (for GCC 4.6).

Comment 8 Jakub Jelinek 2010-07-20 14:55:50 UTC

For QA, artificial testcases distilled from this bugreport (both will be included in the testsuite run during %check):

/* PR debug/45003 */
/* { dg-do run { target { x86_64-*-* && lp64 } } } */
/* { dg-options "-g" } */

int __attribute__((noinline))
foo (unsigned short *p)
{
  int a = *p;
  asm volatile ("nop");
  asm volatile ("nop" : : "D" (a));	/* { dg-final { gdb-test 10 "a" "0x8078" } } */
  return 0;
}

int __attribute__((noinline))
bar (short *p)
{
  unsigned int a = *p;
  asm volatile ("nop");
  asm volatile ("nop" : : "D" (a));	/* { dg-final { gdb-test 19 "a" "0xffff8078" } } */
  return 0;
}

int
main ()
{
  unsigned short us = 0x8078;
  foo (&us);
  short s = -32648;
  bar (&s);
  return 0;
}

and

/* { dg-do run } */
/* { dg-options "-g" } */

struct A { int x; unsigned short y; char z[64]; };

void __attribute__((noinline))
foo (struct A *p, char *q)
{
  int f = &p->z[p->y] - q;
  asm volatile ("nop");
  asm volatile ("nop" : : "g" (f));		/* { dg-final { gdb-test 12 "f" "14" } } */
  asm volatile ("" : : "g" (p), "g" (q));
}

int
main ()
{
  struct A a;
  __builtin_memset (&a, 0, sizeof a);
  a.y = 26;
  a.x = 12;
  asm volatile ("" : : "r" (&a) : "memory");
  foo (&a, &a.z[a.x]);
  return 0;
}

The first test is x86_64 specific, the other one is not.  gdb-test means on that line check value of that variable (a resp. f) is equal to the last operand.

Comment 10 Jakub Jelinek 2010-07-26 20:05:38 UTC

Fixed in gcc-4.4.4-13.el6.  openjdk still needs to be rebuilt with that.

Comment 12 Jon VanAlten 2010-07-28 15:04:54 UTC

Hi,

Any chance this fix could be ported to current Fedora releases?

thanks,

jon

Comment 13 Jakub Jelinek 2010-07-28 15:36:07 UTC

It of course is, see gcc-4.4.4-13.fc{12,13}.  Just it hasn't been pushed as update yet, and won't be until bugfixes accumulate a little bit (-10.fc{12,13} is currently released).

Comment 16 Jakub Jelinek 2010-08-11 09:11:44 UTC

The guality.exp tests are cycled through various -O* optimization levels.  This bug was in VTA, which isn't enabled at all at -O0, so it is expected the test passed before/after the patch at -O0 -g (as the patch didn't change anything in generated code or debug info for that).  It is -O1 -g and higher (or perhaps just -O2 -g or -O3 -g) that matters here.

Comment 18 releng-rhel@redhat.com 2010-11-10 20:25:06 UTC

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. 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.