wade dawson

Wouldnt you just use the workstation/posix port?

allow > 64K QS trace buffer on target

allow > 64K QS trace buffer on target

Hi Miro. I've found out what's happening. Even though NO optimizations are enabled, the vstudio C++17 compiler is intelligent enough to know that certain functions are identical. i.e. //.${HSMs::SyncStreamContro~::SM::ready::r_running::r_r_streaming::await_process} QM_STATE_DEF(SyncStreamControllerHsm, await_process) { QP::QState status_; switch (e->sig) { default: { status_ = Q_RET_SUPER; break; } } return status_; } is functionally equivalent to: //.${HSMs::SyncStreamContro~::SM::ready::r_running::r_r_streaming::r_r_s_process}...

Hi Miro. I've found out what's happening. Even though NO optimizations are enabled, the vstudio C++17 compiler is intelligent enough to know that certain functions are identical. i.e. //.${HSMs::SyncStreamContro~::SM::ready::r_running::r_r_streaming::await_process} QM_STATE_DEF(SyncStreamControllerHsm, await_process) { QP::QState status_; switch (e->sig) { default: { status_ = Q_RET_SUPER; break; } } return status_; } is functionally equivalent to: //.${HSMs::SyncStreamContro~::SM::ready::r_running::r_r_streaming::r_r_s_process}...

Hi Miro. I've run into an issue using QSPY with QPCPP. The same address is being mapped to multiple QS_FUN_DICTIONARY records. I've verified that QS_INIT() is being called before the records are created. "normal_stop,::sm_stop" "resync_stop::sm_stop" and "surprise_stop::sm_stop" are all sm_stop instances so I would expect them to share the same address. However, "await_process::sm_gate_urbs," which shares the same address as the sm_stop instances, is a totally different submachine and the other entries...

Hi Miro. I've run into an issue using QSPY with QPCPP. The same address is being mapped to multiple QS_FUN_DICTIONARY records. I've verified that QS_INIT() is being called before the records are created. "normal_stop,::sm_stop" "resync_stop::sm_stop" and "surprise_stop::sm_stop" are all sm_stop instances so I would expect them to share the same address. However, "await_process::sm_gate_urbs," which shares the same address as the sm_stop instances, is a totally different submachine and the other entries...

Thanks, Miro, I really appreciate it!