Hi,
On Tue, 11 Dec 2018 at 15:20, leo.yan@linaro.org wrote:
On Tue, Dec 11, 2018 at 11:01:11PM +0800, Leo Yan wrote:
[...]
diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h index 37f8d48..fa46ff6 100644 --- a/tools/perf/util/cs-etm.h +++ b/tools/perf/util/cs-etm.h @@ -39,6 +39,26 @@ enum { CS_ETM_PRIV_MAX, };
+/* ETMv3 exception number */ +enum {
CS_ETMV3_EXC_NONE,CS_ETMV3_EXC_DEBUG_HALT,CS_ETMV3_EXC_SMC,CS_ETMV3_EXC_HYP,CS_ETMV3_EXC_ASYNC_DATA_ABORT,CS_ETMV3_EXC_JAZELLE,CS_ETMV3_EXC_RESERVED1,CS_ETMV3_EXC_RESERVED2,CS_ETMV3_EXC_PE_RESET,CS_ETMV3_EXC_UNDEFINED_INSTR,CS_ETMV3_EXC_SVC,CS_ETMV3_EXC_PREFETCH_ABORT,CS_ETMV3_EXC_DATA_FAULT,CS_ETMV3_EXC_GENERIC,CS_ETMV3_EXC_IRQ,CS_ETMV3_EXC_FIQ,+};
/* ETMv4 metadata */ enum { /* Dynamic, configurable parameters */ @@ -53,6 +73,22 @@ enum { CS_ETMV4_PRIV_MAX, };
+/* ETMv4 exception number */ +enum {
CS_ETMV4_EXC_RESET,CS_ETMV4_EXC_DEBUG_HALT,CS_ETMV4_EXC_CALL,CS_ETMV4_EXC_TRAP,CS_ETMV4_EXC_SYSTEM_ERROR,CS_ETMV4_EXC_INST_DEBUG,CS_ETMV4_EXC_DATA_DEBUG,CS_ETMV4_EXC_ALIGNMENT,CS_ETMV4_EXC_INST_FAULT,CS_ETMV4_EXC_DATA_FAULT,CS_ETMV4_EXC_IRQ,CS_ETMV4_EXC_FIQ,+};
I personally think for a best practice, OpenCSD needs to define exception numbers and use them as exception numbers when output exception events; perf cs-etm works as OpenCSD's consumer and directly include OpenCSD header file for these defintions.
I am sorry I don't sync this ealier so can get rid of barriers before upstream this patch series, I accept Mike's suggestion to define exception number in perf header cs-etm.h rather than define them in OpenCSD, just confirm will all of us agree with this?
What appears to be required by this client (perf / cs-etm) is a mapping of number value onto exception 'type' enumeration for ease of reference in client code.. But this interpretation is complex and both architecture and trace protocol specific. The A profile cores typically running linux define a 4 bit exception number in ETMv3 and a 5 bit exception number in ETMv4, and as noted above the mapping of type differing according to protocol - the reset type has a different number in ETMv3/ ETMv4, with different available types reported - the ETMv4 CALL covers all the SVC SMC cases reported in ETMv3.
However, if we look at M class exceptions, then these are different again, with a 10 bit exception number - and lots of new 'types' not defined above.
Any OpenCSD solution must take in all these variants and could not be practically confined to a simple enumerated type - so would require a combination of factors, including perhaps some generic typing supplemented by a value.
It is my view therefore that passing the raw exception number allows a client to interpret the raw data according to requirements.
Regards
Mike
Thanks, Leo Yan
/* RB tree for quick conversion between traceID and CPUs */ struct intlist *traceid_list;
-- 2.7.4