- epicsStackTrace.c provides generic epicsStackTraceGetFeatures() testing
the 'epicsBackTrace()' functionality. Call out to epicsFindAddrGetFeatures()
to inquire about symbol lookup support.
src/libCom/osi/os/posix/osdBackTrace.c => src/libCom/osi/os/posix/osdExecinfoBackTrace.c
src/libCom/osi/os/posix/osdFindAddr.c => src/libCom/osi/os/posix/osdElfFindAddr.c
not all 'posix' platforms can use the above versions (since the used APIs are not really POSIX)
but a subset can. The platforms which can use either version #include it from 'their'
osdBackTrace.c/osdFindAddr.c.
is non-standard either and AFAIK always based on the latter.) Always
using dladdr allows us to precisely control the printout formatting
and keep it consistent.
1) Added a paranoia test to make sure an ill-formatted
ELF string table is not overrun if there is no NULL
char found.
2) Added errlogFlush() before and after stack dump (suggestion
by Michael Davidsaver, thanks).
3) Fixed (out of sync) debug messages.
Circular initialization problem that Murali discovered when you
try to fprintf(stderr) from the posix/osdThread.c once() routine.
This change lets the stderr stream through in that case.
The __STDC_VERSION__ >= 199901L test never succeeds
in C++, and there were issues with the epicsInt8
definition anyway (int8_t is signed, but char might
not be).
I also removed the epicsBoolean enum which we never use.
Using the m_ prefix to denote class data members is dangerous in
code that has to compile on VxWorks 5.5 (which 3.15 does) because
the net/mbuf.h header contains the following macro definitions:
#define m_next mBlkHdr.mNext
#define m_len mBlkHdr.mLen
#define m_data mBlkHdr.mData
#define m_type mBlkHdr.mType
#define m_flags mBlkHdr.mFlags
#define m_nextpkt mBlkHdr.mNextPkt
#define m_act m_nextpkt
#define m_pkthdr mBlkPktHdr
#define m_ext pClBlk
#define m_extBuf m_ext->clNode.pClBuf
#define m_extFreeRtn m_ext->pClFreeRtn
#define m_extSize m_ext->clSize
#define m_extRefCnt m_ext->clRefCnt
#define m_extArg1 m_ext->clFreeArg1
#define m_extArg2 m_ext->clFreeArg2
#define m_extArg3 m_ext->clFreeArg3
#define m_copy(m, o, l) m_copym((m), (o), (l), M_DONTWAIT)
#define m_copym(m, o, l, w) netMblkChainDup(_pNetDpool, (m), (o), (l), (w))
#define m_freem(m) netMblkClChainFree(m)
#define m_free(m) netMblkClFree(m)
#define m_mbufs mNum
#define m_drops mDrops
#define m_wait mWait
#define m_drain mDrain
#define m_mtypes mTypes
While the names in the original change all appear to be safe, I
don't want us to start using this convention because we will then
have to police commits more closely or risk build failures in the
future when someone who doesn't know about or remember the issue
can't or doesn't try building their code against VxWorks 5.5.
I don't particularly like the this-> convention to mark member
names either, but until the VxWorks 5.5 support requirement goes
away the m_ convention is worse. Another common convention of
using a leading underscore is not safe either, those names are
reserved for the C/C++ implementation.
