[LLVMbugs] [Bug 2515] New: execution of scanf functions broken in lli

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=2515

           Summary: execution of scanf functions broken in lli
           Product: tools
           Version: 2.3
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: critical
          Priority: P2
         Component: lli
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hvdieren at elis.ugent.be
                CC: llvmbugs at cs.uiuc.edu


Hi,

When running SPEC benchmarks in lli, I found that the execution of scanf()
functions is broken. Here is a description of what goes wrong:

1. mcf benchmark calls sscanf()
2. lli ends up in ByteswapSCANFResults()
(lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp)
   which executes this code for every argument to sscanf():
        if (Size) {
          GenericValue GV;
          void *Arg = Args[ArgNo++];
          memcpy(&GV, Arg, Size);
          TheInterpreter->StoreValueToMemory(GV, (GenericValue*)Arg, Ty);
        }
  The problem is in the definition of GenericValue and the use of memcpy():
include/llvm/ExecutionEngine/GenericValue.h:
struct GenericValue {
  union {
    double          DoubleVal;
    float           FloatVal;
    PointerTy       PointerVal;
    struct { unsigned int first; unsigned int second; } UIntPairVal;
    unsigned char   Untyped[8];
  };
  APInt IntVal;   // also used for long doubles

  GenericValue() : DoubleVal(0.0), IntVal(1,0) {}
  explicit GenericValue(void *V) : PointerVal(V), IntVal(1,0) { }
};

After scanning the value 5985, memcpy() leaves this value into GV:
(gdb)
#5  0x00000000008d666e in ByteswapSCANFResults (Fmt=0x11aaa23 " %ld",
Arg0=0x11ab410, Arg1=0x11aba60, Arg2=0x7fff4a881a20, Arg3=0x10f5690,
Arg4=0x7fff4a8819f0,
    Arg5=0x8fa236, Arg6=0x11aad70, Arg7=0x7fff4a881a38, Arg8=0x0) at
/.../llvm-2.3/lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp:466
466               TheInterpreter->StoreValueToMemory(GV, (GenericValue*)Arg,
Ty);
(gdb) p GV
$33 = {{DoubleVal = 2.9569828903598606e-320, FloatVal = 8.38677131e-42,
PointerVal = 0x1761, UIntPairVal = {first = 5985, second = 0},
    Untyped = "a\027\000\000\000\000\000"}, IntVal = {BitWidth = 1, {VAL = 0,
pVal = 0x0}}}

The memcpy call does not overwrite the IntVal field.

The problem appears to be that, for the memcpy() trick to work, the IntVal must
be part of the union in GenericValue. It appears, however, that the structure
of GenericValue has been unchanged since 15 months. (So how about tests for
this code?)

The problem is also signalled by an assert(), because the bitwidth of the
IntVal is initialized to 1, but this is not conforming the size of the type Ty.
Assertion `(IntVal.getBitWidth()+7)/8 >= StoreBytes && "Integer too small!"'

All of this is on x86-64 running redhat linux.

Hans.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.