Code review comment for lp:~strauman/epics-base/stacktrace-1

On a related note:

I just looked at epicsFindSymbol() and wanted to point out that this API
is not implemented
in a thread-safe way (the posix variant, that is). The standard says

"It is implementation-defined whether or not the /dlerror/() function is
thread-safe.
  A thread-safe implementation shall return only errors that occur on
the current thread."

(http://pubs.opengroup.org/onlinepubs/9699919799/)

A little test reveals that (at least: recent, i.e., ubuntu 14.04, osx
10.9) linux + osx are
thread-safe but solaris is not.

- T.

On 09/03/2014 02:42 PM, Andrew Johnson wrote:
> Since both implementations of epicsStackTraceGetFeatures() return a constant that is calculated at compile-time don't see the need for this to be a function; an extern const int would work just as well.
>
> I agree with Michael's comment about reworking elfLookupAddr(); we have been trying to remove architecture-specific conditionally compiled code where possible, providing a common set of osd*() routines in the libCom/osi/os/osd*.c files that the higher-level implementation can call. This makes the code much easier to read and debug IMHO. The execinfoStackTrace.c file currently has more #ifs and #ifdefs in it than all the rest of libCom/osi/*.c[pp] put together.
>
> Which of our platforms will use the elfLookupAddr() implementation? There would seem to be some conceptual overlap between this and the epicsFindSymbol() API (in epicsFindSymbol.h and os/*/osdFindSymbol.c), although that is looking for an address given the symbol name, which is the opposite usage.
>
> VxWorks provides a routine tt(taskId) for printing stack-traces but the output is sent directly to the OS's stdout or stderr, and the internals of the implementation are not accessible. Oh, and tt() can't trace its own thread either, so it's not much use to us for this anyway.
>