lkml.org 
[lkml]   [1996]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ALERT! Stay away from patched gcc's (was Re: 2.0.22 will be the last version)

    As some people have asked me how the bad code actually looks like, I'm
    posting a short description of what happe with the bad gcc version.

    The bad code happens with the new inline assembly code for semaphores (it
    _probably_ happens with other inline assembly code too, though - the
    semaphore code is in no way special among linux inline asm usage). The
    "down()" operation is defined as:

    extern inline void down(struct semaphore * sem)
    {
    __asm__ __volatile__(
    "# atomic down operation\n"
    "1:\n\t"
    "movl $1b,%%eax\n\t"
    #ifdef __SMP__
    "lock ; "
    #endif
    "decl %0\n\t"
    "js " SYMBOL_NAME_STR(down_failed)
    :/* no outputs */
    :"m" (sem->count), "c" (sem)
    :"ax","dx","memory");
    }

    Note especially the fact that the asm statement marks registers ax and dx as
    being destroyed by the statement (%eax is used as a "return" address and is
    loaded here, while %edx is potentially destroyed by the functions calls that
    are called from "down_failed").

    The problem is that this bad gcc doesn't take this into account, the code
    produced in sd_init_onedisk looks like this:

    ...
    call scsi_do_cmd
    addl $0x1c,%esp
    movl 16(%esp),%ecx
    movl 16(%esp),%eax

    /* down operation starts here */
    movl $0x18d9dc,%eax
    decl (%eax)
    js 0x19bfa0 <down_failed>
    /* end of down operations */

    movl 0xf0(%edi),%esi
    incl %ebx
    testl %esi,%esi
    je sd_init_onedisk+633
    movb 0x8a(%edi),%dl
    ...

    Note the use of "decl (%eax)" - gcc is allocating %eax for the input of the
    down operation, even though the asm has marked %eax clobbered. And I quote
    from the gcc info pages:

    "The input operands are guaranteed not to use any of the clobbered
    registers, and neither will the output operands' addresses, so you can read
    and write the clobbered registers as many times as you like"

    so this is definitely a buggy gcc that has produced the code above. But from
    all reports it seems that gcc-2.7.2 and gcc-2.7.2.1 are ok, and there are
    also version of the no-strength-reduce bugfix that are ok. Werner Fink is on
    vacation right now, so I still don't know exactly what version of gcc he is
    using (he did mention gnat, are there patches to the gcc back-end for ada
    too?).

    Linus


    \
     
     \ /
      Last update: 2005-03-22 13:38    [W:0.021 / U:30.088 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site