Topic: [SOLVED] Can libc functions be totally avoided?

Hi All.

Via awesome help via https://www.wolfssl.com/forums/topic113 … u1404.html , I have been able to run our application on Ubuntu-14.04, with all data being secured-over-wire.  Thanks Kaleb !!!

Now, I am trying to port the application to a SOC, using an ARM-processor.
Compilation has proceeded forward a good deal, however, I get the following errors ::

undefined reference to _open
undefined reference to _gettimeofday

Upon some googling, it looks that these are being caused due to linking of libc.a (I am using Atmel-Studio for compiling for SOC).


Also, following are the (additional) settings ::

#define HAVE_ECC
#define HAVE_ECC_SIGN
#define HAVE_ECC_VERIFY
#define HAVE_ECC_DHE
#define HAVE_ECC_KEY_IMPORT
#define HAVE_ECC_KEY_EXPORT

#define XMALLOC_USER
#define SINGLE_THREADED
#define NO_WRITEV
#define NO_AES
#define NO_FILESYSTEM
#define WOLFSSL_SMALL_STACK

Is there a way to overcome the errors? Or better still, to totally avoid linking of libc.a?


Thanks and Regards,
Ajay

Share

2 (edited by Kaleb J. Himes 2017-11-27 15:46:01)

Re: [SOLVED] Can libc functions be totally avoided?

Hi Ajay,

_open and _gettimeofday are usually part of the rdimon spec library. This can be resolved typically in a cross-compile build by adding the following:


# WHERE ${LIBS} is any other libraries you might need
WOLF_OPTS := --specs=rdimon.specs -Wl,--start-group ${LIBS} -lgcc -lm -lc -lrdimon -Wl,--end-group

Then add ${WOLF_OPTS} to your build rule for the object.

Warmest Regards,

Kaleb

Re: [SOLVED] Can libc functions be totally avoided?

Thanks Kaleb for the reply.

Actually, my purpose was/is to remove any OS-specific dependencies, and make the code as bare-metalized as possible.


a)
I figured out that the _open was being called from the default implementation of

int wc_GenerateSeed(OS_Seed* os, byte* output, word32 sz)

in random.c , that opened a file-descriptor to /dev/random.

Now, since the default-implementation is only for linux-like systems, so I moved this to our device-specific section in our framework. In wolfSSL's world, this would mean using CUSTOM_RAND_GENERATE_SEED.


b)
For _gettimeofday, I used the bare-metal implementation

int _gettimeofday( struct timeval *tv, void *tzvp )
{
    uint64_t t = getCurrentTick();
    tv->tv_sec = t;
    tv->tv_usec = 0;
    
    return 0;
}

where struct timeval is primitive, and getCurrentTick again resides in the device-specific section.


Please mark this thread as solved.



Thanks and Regards,
Ajay

Share