From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-411885-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12618 invoked by alias); 11 Jan 2013 11:17:20 -0000
Received: (qmail 12524 invoked by uid 48); 11 Jan 2013 11:16:50 -0000
From: "fm3 at os dot inf.tu-dresden.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/55940] New: Incorrect code for accessing parameters with 32-bit Intel hosts
Date: Fri, 11 Jan 2013 11:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fm3 at os dot inf.tu-dresden.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-55940-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2013-01/txt/msg01004.txt.bz2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940

             Bug #: 55940
           Summary: Incorrect code for accessing parameters with 32-bit
                    Intel hosts
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: fm3@os.inf.tu-dresden.de


There are some reports about incorrect compiled Linux kernel modules for
VirtualBox. I've debugged one report (see here:
https://www.virtualbox.org/ticket/11035) and saw that the compiler generated
invalid code for accessing parameters inside a function. When it should read
the parameter from the stack it reads the parameter from a register.

I don't know exactly under which circumstance this happens but this seems to be
related to 32-bit x86 targets. The function VBoxHost_RTR0MemObjGetPagePhysAddr
is marked as __attribute__((cdelc, regparm(0))). The pre-processed
memobj-r0drv.i file is attached to that ticket. The generated code is part of
the vboxdrv.ko file which is also attached to the ticket.

The following code is generated to access the first function parameter (keep
cdecl in mind!):

VBoxHost_RTR0MemObjGetPagePhysAddr():
/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/r0drv/memobj-r0drv.c:268
    955e:       8b 0f                   mov    (%edi),%ecx
    9560:       8b 47 04                mov    0x4(%edi),%eax
/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/r0drv/memobj-r0drv.c:272
    9563:       8d 91 00 10 00 00       lea    0x1000(%ecx),%edx

So the function is using the EDI register to access the parameter while it
should read the parameter from the stack.

The C code of this function looks (see memobj-r0drv.i) is:

RTHCPHYS __attribute__((cdecl,regparm(0)))
VBoxHost_RTR0MemObjGetPagePhysAddr(RTR0MEMOBJ MemObj, size_t iPage)
{

    PRTR0MEMOBJINTERNAL pMem;
    size_t cPages;
    do { if (__builtin_expect(!!(!(( (uintptr_t)(MemObj) + 0x1000U >= 0x2000U
))), 0)) return ((~(RTHCPHYS)0)); } while (0);
    ...

(Explanation of the code: This is actually a sanity check if the pointer is
valid; the value must be either less than 0xFFFFF000U or greater than
0x00000FFFU).

Unfortunately I cannot reproduce this problem myself (gcc 4.7.2 on my Linux
distribution creates correct code). The gcc compiler the user is using is

gcc version 4.7.2 (Exherbo gcc-4.7.2-r2)

(see comment 18 in the above ticket).