memcpy in queue.c

Kernel
1

jwestmoreland wrote on Monday, June 05, 2006:

Richard,

I was wondering what the issues can be of using a memcpy from the target’s CLIB that may not be reentrant - or other string functions.

queue.c includes both stdlib and string.h files.

Thanks,
John W.

2

rtel wrote on Monday, June 05, 2006:

These functions definitely need to be reentrant and although the scheduler code should guard against pseudo simultaneously calls it cannot guard against the application code making similar calls.

I would be amazed if this function was ever not reentrant, although many of the SDCC libraries are not (hence I provide a download of reentrant versions).

The design decision was taken to use the library function as it was considered more likely to be the source of errors if an equivalent function were defined in the portable layer (as different memory alignment requirements could cause problems).

Do you think you may have found an issue?

Regards.

3

jwestmoreland wrote on Monday, June 05, 2006:

Richard,

I’m still investigating this.  If I have found an issue - it is only in my MSP430 IAR port.

I’ve discussed this with IAR and they have told me the functions are reentrant - but I need to do further testing to determine if I’ve hit some kind
of corner case.

Thanks,
John W.

4

rtel wrote on Monday, June 05, 2006:

I think you will find the memcpy source in:
IAR Systems\Embedded Workbench 4.0\430\src\lib\clib

looks reentrant.

Regards.

5

jwestmoreland wrote on Monday, June 05, 2006:

Is memcpy the only function to worry about?

Thanks,
John

6

rtel wrote on Tuesday, June 06, 2006:

I think strncpy() is used to copy the task name into the TCB - so only when a task is created.  Other than that the library functions are used when configUSE_TRACE_FACILITY is defined and you are creating a table of the task status.

Regards.

7

jwestmoreland wrote on Tuesday, June 06, 2006:

Richard,

I have noticed this - and this is in my app - not the core FreeRTOS code.  If I do something like this - back to back:

memset
memcpy
strtoul

I get results in the debugger that seemingly aren’t ‘real’.  If I run ‘realtime’ - all seems to be well - but if I set breakpoints and try to examine - I get conflicting results.  An example -
I initialize a ‘packet’.  Part of the ‘packet’ get’s memcpy(ied) like above - but when I stop the debugger and look at the packet contents - it shows the initialized values - even though this is impossible.  Kindof strange - I noticed it’s hard to debug if you have too many back-to-back lib functions stacked up for some reason…

Thanks,
John

8

rtel wrote on Tuesday, June 06, 2006:

I can’t see why calling library functions would be any different to calling your own defined functions, but here are some random thoughts:

+ Some library functions can use a lot of stack. memset and memcpy should use hardly any, but strtoul has potential to use a bit.

+strtoul seems to be reentrant having had a quick scan of the code.

+ Some compilers will inline some smaller library functions as a matter of coarse.  Could this be messing up your debug attempts?

Regards.

9

jwestmoreland wrote on Tuesday, June 06, 2006:

Richard,

I don’t think I’m having a problem with inlining - but I’ll check that.  I suppose that could explain the issue with trying to debug with back to back lib  calls.

Thanks,
John W.