Set _ep_arch_info for s390x

[uweigand]

• Add missing clause setting the _ep_arch_info variable

[tommcdon]

@josalem @lateralusX

[lateralusX]

Question, that CPU arch, what endianness does it support? Code in EventPipe (or at least consumers of nettrace file format), assumes data is emitted as little endian, so if some data will start to be emitted as big endian, they will not be correctly represented in parsing tools.

[uweigand]

Question, that CPU arch, what endianness does it support? Code in EventPipe (or at least consumers of nettrace file format), assumes data is emitted as little endian, so if some data will start to be emitted as big endian, they will not be correctly represented in parsing tools.

s390x is big-endian. I see that code in eventpipe writes binary data in native byte order, so if the consumers expect this to always be little-endian, then this is a problem.

I haven't seen any issues in practice so far, however, so I'm wondering if I'm running all test cases I should be running here. What's the best way to test this subsystem? (Note that on s390x we're currently only supporting the Mono runtime.)

[lateralusX]

Question, that CPU arch, what endianness does it support? Code in EventPipe (or at least consumers of nettrace file format), assumes data is emitted as little endian, so if some data will start to be emitted as big endian, they will not be correctly represented in parsing tools.

s390x is big-endian. I see that code in eventpipe writes binary data in native byte order, so if the consumers expect this to always be little-endian, then this is a problem.

I haven't seen any issues in practice so far, however, so I'm wondering if I'm running all test cases I should be running here. What's the best way to test this subsystem? (Note that on s390x we're currently only supporting the Mono runtime.)

There are low level tests under tests/tracing/eventpipe that runs several produce/consumer scenarios as well as different EventPipe scenarios, but they all run on the same machine, so data will be read back exactly as serialized into nettrace binary format. I guess issues will manifest once you try to parse a nettrace file on a different arch using tools like perfview or TraceEvent library. I don't think the tools make specific assumptions about endianess, but since all just consume the binary data as serialize, currently the produce and consumer needs to run on the same endiness, so in order to get Windows tools like perfview/VS to work, all data serialized into a nettrace file needs to be in little endian format.

[lateralusX]

Also note that we have had some issue running EventPipe tests on Mono CI, due to test marked as sensitive to tiered JIT has not been executed. I discovered this last week, so working on #58106 to make sure we get them up and running on platforms where we currently can run EventPipe automation.

[lateralusX]

In order to include diagnostics_tracing you need to include that component in build, but maybe you already build using static component support? If so all components (tracing, debugger, hot_reload) will be part of runtime build. If you do dynamic component build, then needed components needs to be deployed during test in order to be loaded and used by runtime. You can find some more details around component support, https://github.com/dotnet/runtime/blob/main/docs/design/mono/components.md and how for example tracing is used by Android/iOS, https://github.com/dotnet/runtime/blob/main/docs/design/mono/diagnostics-tracing.md.

[uweigand]

Thanks for the pointers. I'll see if I can get the testsuite going, and if I can find a way to run some cross-platform testing.

[akoeplinger]

Should we merge this PR in the meantime? We'll need this change regardless of the endianess topic.

[lateralusX]

Yes I think we could do that, it didn't prevent from running EventPipe code in the past on this platform, it is just info that goes into nettrace file as well as used in process info IPC commands.