Topic: CCS Assembler, and defects all over the place.

Hello,
I have built the WolfSSL as a standalone static library inside CCS, using the TI compiler.

Now I have a bunch of problems trying to do this in CCS with the GNU compiler.

I have a couple of questions regarding what I discovered at the end of this post.

In my opinion, CCS is a trainwreck, and TI is usually of little help.
A lot of this is coming from the *.S files in folder WolfSSL-4-5\Wolf\wolfcrypt\src\port   (root folder is my naming)

And it's because a couple of source files (like "armv8-curve25519.s")  have #includes in it, where most others don't

I compile armv8-curve25519.c  and get 1000's of errors. I can't even see the original command line, since it scrolls off the output so fast...

1.  It shouldn't compile anything because #ifdef WOLFSSL_ARMASM is NOT defined anywhere I can find.  But CCS has a nasty habit of dragging in stuff I don't want, hiding the way things are defined, etc...  So I had to try it another way.

Since the editor highlight is not showing me if #defines are actually defined, I did the following to one of the source files:

#ifdef WOLFSSL_ARMASM
#error  THIS IS ENABLED

This compiled...  But

#error  THIS IS ENABLED
#ifdef WOLFSSL_ARMASM

Gave me the expected error.

So I can tell that WOLFSSL_ARMASM is NOT defined which helps give me a clue for more digging...

2. Next I discover that CCS has decided that it wants to compile the ASSEMBLER FILE armv8-curve25519.S even when I tell it not to. 
I right click on the *.c file, select 'build selected file', but it still compiles the *.S file.
I right click on the *.S file and EXCLUDE IT, but CCS still compiles the *.S file for the *.c file.

(did I say trainweck? I am being polite)

Anyway the *.S file has at the top:

#ifdef HAVE_CONFIG_H
    #include <config.h>
#endif /* HAVE_CONFIG_H */
#include <wolfssl/wolfcrypt/settings.h>

/* Generated using (from wolfssl):
 *   cd ../scripts
 *   ruby ./sha2/sha512.rb arm64 ../wolfssl/wolfcrypt/src/port/arm/armv8-sha512-asm.S
 */
#ifdef WOLFSSL_ARMASM

And the "wolfssl/wolfcrypt/settings.h" file then drags in

#include <ti/sysbios/hal/Seconds.h>

Which then opens the floodgates for XDC and SYSBIOS header files.

The result is that it's reading all the XDC and SYSBIOS code and trying to compile it like assembler.

My solution to work around this is the move the #ifdef to the top...

#ifdef WOLFSSL_ARMASM
#ifdef HAVE_CONFIG_H
    #include <config.h>
#endif /* HAVE_CONFIG_H */
#include <wolfssl/wolfcrypt/settings.h>

Is this a viable workaround?  I don't know why this hasn't been discovered earlier, when someone wants to compile the assembler file.

I see a problem here in that I can never get those assembler files to compile as they have those #includes which breaks the build.

And the assembler files appear to be identical to the code in the C files.  So they appear to be redundant.  It that correct?

Are those ciphers in that folder supported in another way?  Or do I have to enable one of those files (*.c or *.S) to get those ciphers built and included?

Thanks in advance for any advice.

-Scott
<Code shown is not to scale>

Share

Re: CCS Assembler, and defects all over the place.

Hi Scotty2541,

Sorry to hear that you are having issues building wolfSSL library.

It looks like you are running into a common problem with Eclipse performing a wildcard search of *.c and *.s files and building all source code.

I think your proposed solution to add `#ifdef WOLFSSL_ARMASM` is good.


The preferred alternative solution is to remove source codes that are not relevant to your platform.
Specifically, you need to remove platform-specific assembly source files in
    -   wolfssl/wolfcrypt/src/port/*`dir
    -   wolfsslPort/wolfcrypt/src/aes_asm.asm
    -   wolfsslPort/wolfcrypt/src/aes_asm.S

Please let me know if this helps.

Share

Re: CCS Assembler, and defects all over the place.

Thanks.
I will keep the #ifdef solution because we like to have all the original code packaged together.   Not delete pieces...  It makes more work to remember all those things when integrating the next update.

As to my other question:

Are those ciphers in that folder supported in another way?  Or do I have to enable one of those files (*.c or *.S) to get those ciphers built and included?

I know I can set the ciphers with:

wolfSSL_CTX_set_cipher_list(ctx, cipherList);

But what if all those ciphers are not compiled in?

I'm only learning to navigate the complexities of SSL, so I don't know.

-Scott
<Code shown is not to scale>

Share