On Wed, Dec 12, 2018 at 12:24:35PM +0000, Mike Leach wrote:
[...]
+/* 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.
Yeah, have noted this when wrote enum structures for ETMv3 and ETMv4.
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.
Yeah, when I read the string array for exceptions and found M class have their own different definition.
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.
I understand now, seems to me OpenCSD just pass through the number to Linux perf and OpenCSD doesn't use the number, hence Linux perf needs to know meaning for the number by itself.
This is reasonable to me; so I don't have strong opinion now and want to get feedback from Mathieu before move forward :)
Thanks, Leo Yan