Xcode4, libtomcrypt, LLVM, asm (unknown version of libtomcrypt) about libtomcrypt HOT 13 CLOSED

as far as I can see you're using 1.16
[edit]but you seem to have modified some files. e.g. the "attribute((always_inline))" isn't in the sources of the standard 1.16 tomcrypt_macros.c[/edit]

from libtomcrypt.

I wasn't the one that made those attribute changes. Still...good to see that there's something.

Does the latest version use those attributes as well?

from libtomcrypt.

I am presently attempting to get Stempania 3.9 to build on Lion (which is more of a challenge, I suspect) and am seeing this error. Though extra bizarrely I seem to only see it when I execute the build from the XCode GUI. If I use xcodebuild from the command line it seems to build cleanly (though I haven't gotten the rest to build enough to have any hope of testing linking yet).

from libtomcrypt.

It seems like the difference, at least for 3.9 may be that the GUI seems to be hitting the "Debug" configuration, whereas xcodebuild is using the "Native" configuration. I have't looked into it deeper than that.

from libtomcrypt.

I ran into this issue as well. The workaround I ended up doing was to add #define LTC_NO_ROLC to tomcrypt_custom.h.

I think the issue is that the ROLc and RORc functions attempt to emit rotate instructions with a hard-coded literal, from the parameter i. This is what the asm constraint "I" means. Since the functions are specified as inline, the compiler could end up replacing the (i) parameter in the asm with a literal, in which case it works fine.

ROLc is defined as:

static inline unsigned ROLc(unsigned word, const int i)
{
   asm ("roll %2,%0"
      :"=r" (word)
      :"0" (word),"I" (i));
   return word;
}

I believe the intent is for something like y = ROLc(x, 3) to get rewritten as follows before getting handed off to the assembler:

asm ("roll %2,%0"
  :"=r" (x)
  :"0" (x),"I" (3));
y = x;

However, if the function doesn't get inlined, or the compiler doesn't optimize (i) to a literal constant as a result of inlining, then the constraint "I" will indeed be invalid.

It sounds like someone tried to address this issue in your codebase by forcing the compiler to always inline. Unfortunately this won't work if the attribute gets ignored, or if the compiler doesn't do the further optimization of replacing (i) with the literal parameter.

I think that the most portable fix would be to make ROLc and RORc macros instead of functions.

from libtomcrypt.

I thought I'd go ahead and give a quick try for redefining ROLc and RORc as macros. The tricky part is that an asm block is a statement, not an expression. The only way I can think to do it is using statement expressions, which are supported by both gcc and clang, but are not ansi c.

We also need to copy the parameter to avoid changing its value and to handle the case where the parameter isn't an lvalue.

Anyways, the following compiles, but I haven't tested for correctness:

#define ROLc(word, i)                           \                                                            
  ({ unsigned __rotd;                           \                                                            
    __rotd = (word);                            \                                                            
    asm ("roll %2,%0"                           \                                                                     :"=r" (__rotd)                         \                                                            
         :"0" (__rotd),"I" (i));                \                                                            
    __rotd; })                                                                                               

#define RORc(word, i)                           \                                                            
  ({ unsigned __rotd;                           \                                                            
    __rotd = (word);                            \                                                            
    asm ("rorl %2,%0"                           \                                                            
         :"=r" (__rotd)                         \
         :"0" (__rotd),"I" (i));                \
    __rotd; })

from libtomcrypt.

how about using the old trick: do { code_here(); } while(0)

from libtomcrypt.

how about using the old trick: do { code_here(); } while(0)

That trick only works to replace a function that returns void. This one needs to return the rotated value. Here's an example call site from aes.c:

rk[12] = rk[ 4] ^ setup_mix(RORc(temp, 8));

(edited for clarification)

from libtomcrypt.

Incidentally, I think the reason I'm hitting this bug is because I'm compiling with -O0, causing gcc to skip the inlining. I'm including tomcrypt as part of a larger project build, from which the tomcrypt build inherits some CFLAGS. i.e., the bug can be replicated with gcc on the stock code base by:

make CFLAGS="-O0 -I./src/headers -DLTC_SOURCE"

from libtomcrypt.

@sporksmith did you try to define the function with __attribute__((always_inline))?

from libtomcrypt.

I don't remember whether we tried __attribute__((always_inline)) or not. I imagine it would work, if gcc honors that attribute even at -O0.

We ended up solving it by just not having the tomcrypt build inherit the CFLAGS from the project build. I.e., let tomcrypt compile at -O2, in which case the functions gets inlined and this bug doesn't surface.

from libtomcrypt.

Proposed solution in this pull request

from libtomcrypt.

pull/125 was closed, can we also close this issue?

from libtomcrypt.