Compiler/AM1705: Probably badly generated code

Jiří Tuháček

Prodigy 40 points

Part Number: AM1705

Tool/software: TI C/C++ Compiler

Hi,

I encountered a problem during the compiling of the wolfssl library. In function wc_AesDecrypt there is code like this:

#define GETBYTE(x, y) (word32)((byte)((x) >> (8 * (y))))

…

static const byte Td4[256] = {…}

…

s0 =

((word32)Td4[GETBYTE(t0, 3)] << 24) ^

((word32)Td4[GETBYTE(t3, 2)] << 16) ^

((word32)Td4[GETBYTE(t2, 1)] << 8) ^

((word32)Td4[GETBYTE(t1, 0)]) ^

rk[0];

Compiling is done in order, but the application crashes. The problem seems to be that in the GETBYTE macro, the result of the expression is not correctly cropped to BYTE so Td field is indexed beyond the boundary. If the macro is replaced by (((x) >> (8 * (y))) & 0xFF) everything is fine.

I tried compilers tms470_4.9.7, ti-cgt-arm_5.2.9 and ti-cgt-arm_16.9.3 with same results. C64+ DSP compilers works fine.

Please tell me what’s wrong.

Thanks
Jiri

over 8 years ago

0 Keith Barkley over 8 years ago

Guru 42215 points

Is word32 signed or unsigned?

0 George Mock over 8 years ago

TI__Guru**** 251230 points

Please supply a test case by following the directions in the article How to Submit a Compiler Test Case. In addition, indicate the name of the function which contains the problem use of the macro GETBYTE.

Thanks and regards,

-George

0 Jiří Tuháček over 8 years ago in reply to Keith Barkley

Prodigy 40 points

Both types (byte and word32) are unsigned

0 George Mock over 8 years ago in reply to Jiří Tuháček

TI__Guru**** 251230 points

Unfortunately, I remain unable to reproduce the problem. Please submit a test case as previously requested.

Thanks and regards,

-George

0 Jiří Tuháček over 8 years ago in reply to George Mock

Prodigy 40 points

I attached two files, one preprocessed C source and second one is generated asm output with marked line where it crashed (look for !!! symbol).

Code is generated by tms470_4.9.7, with following switches:

cl470.exe -c -fe aes.obj -DMODEL_TYPE=MODEL_TYPE_ACCESSUNIT --verbose_diagnostics --abi=eabi --relaxed_ansi --gen_func_subsections
=on -DTIARM -D__TIARM__ -mv=5e --little_endian --code_state=32 -O3 --symdebug:dwarf ../../_lib/wolfssl/wolfcrypt/src/aes.c -k -al -ss

Thanks for help

Jirka

2133.aes.pp.txt

aes.asm.txt

0 Archaeologist over 8 years ago in reply to Jiří Tuháček

TI__Guru* 84285 points

I'm looking at it right now, but it's slow going. It would be very helpful if you could provide a sample test harness; that is, a main function that calls wc_AesCbcDecrypt with the same input it has when it malfunctions.

0 Archaeologist over 8 years ago

TI__Guru* 84285 points

Are you absolutely sure ARM 16.9.3 gives you the same incorrect results? I'm seeing very different code with that version

0 Archaeologist over 8 years ago in reply to Archaeologist

TI__Guru* 84285 points

Eh, never mind. I think I've isolated the bug. I've submitted defect report CODEGEN-2320 to track the issue.

0 Jiří Tuháček over 8 years ago in reply to Archaeologist

Prodigy 40 points

It is difficult to do the sample test because the fragment is part of a large piece of code and can not be isolated. It is true that version 16.9.3 generates completely other code, but it still falls. Unfortunately, I can't analyze the problem deeper, because I have small knowledge of ARM assembler.

Code Composer Studio™︎

Code Composer Studio forum

Compiler/AM1705: Probably badly generated code