[Bug gdb/22491] gdb.arch/amd64-stap-optional-prefix.exp fails after probe C++-ification patch

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22491

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Sergio Durigan Junior
<sergiodj@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=685de8c2990a04fba5e2954b7ff089a2c641071f

commit 685de8c2990a04fba5e2954b7ff089a2c641071f
Author: Sergio Durigan Junior <sergiodj@redhat.com>
Date:   Sat Nov 25 01:13:03 2017 -0500

    Fix PR gdb/22491: Regression when setting SystemTap probe semaphores

    Pedro has kindly pointed out that
    gdb.arch/amd64-stap-optional-prefix.exp was failing after my
    C++-ification patches touching the probe interface.  The failure is
    kind of cryptic:

     77 break -pstap bar
     78 Breakpoint 3 at 0x40048d
     79 (gdb) PASS: gdb.arch/amd64-stap-optional-prefix.exp: bar: break -pstap
bar
     80 continue
     81 Continuing.
     82
     83 Program received signal SIGILL, Illegal instruction.
     84 main () at amd64-stap-optional-prefix.S:26
     85 26              STAP_PROBE1(probe, foo, (%rsp))

    It took me a while to figure out where this SIGILL is coming from.
    Initially I thought it was something related to writing registers to
    the inferior when dealing with probe arguments, but I discarded this
    since the arguments were not touching any registers.

    In the end, this was a mistake that was introduced during the review
    process of the patch.  When setting/clearing a SystemTap probe's
    semaphore, the code was using 'm_address' (which refers the probe's
    address) instead of 'm_sem_addr' (which refers to the semaphore's
    address).  This caused GDB to write a bogus value in the wrong memory
    position, which in turn caused the SIGILL.

    I am pushing this patch to correct the mistake.

    On a side note: I told Pedro that the BuildBot hadn't caught the
    failure during my try build, and for a moment there was a suspicion
    that the BuildBot might be at fault here.  However, I investigate this
    and noticed that I only did one try build, with a patch that was
    correctly using 'm_sem_addr' where applicable, and therefore no
    failure should have happened indeed.  I probably should have requested
    another try build after addressing the review's comments, but they
    were mostly basic and I didn't think it was needed.  Oh, well.

    2017-11-25  Sergio Durigan Junior  <sergiodj@redhat.com>

        PR gdb/22491
        * stap-probe.c (relocate_address): New function.
        (stap_probe::get_relocated_address): Use 'relocate_address'.
        (stap_probe::set_semaphore): Use 'relocate_address' and pass
        'm_sem_addr'.
        (stap_probe::clear_semaphore): Likewise.

-- 
You are receiving this mail because:
You are on the CC list for the bug.