[Eventpipe][S390X] Fix Session_Id for s390x

[saitama951]

while sending a StopTracingCommand via IPC from dotnet-gcdump, the payload consists the session_id which is not passed in the correct endian order to ep_disable which in-turn keeps the tracing going on indefinitely

[lateralusX]

Since we no longer can consume the payload as is, the pattern is to implement a parse function passed to ds_ipc_message_try_parse_payload that would setup the fields correct, handling endianness etc. Following that pattern we would implement a parsing function for EventPipeStopTracingCommandPayload that would handle the session_id as expected and then ep_disable could just use the field as normal since its already correctly parsed.

[saitama951]

if we parse the session_id in the correct order before-hand,
then this would parse incorrect session_id value to ipc stream,

static
bool
eventpipe_protocol_helper_send_stop_tracing_success (
        DiagnosticsIpcStream *stream,
        EventPipeSessionID session_id)
{
        EP_ASSERT (stream != NULL);

        bool result = false;
        DiagnosticsIpcMessage success_message;
        if (ds_ipc_message_init (&success_message)) {
                result = ds_ipc_message_initialize_header_uint64_t_payload (&success_message, ds_ipc_header_get_generic_success (), (uint64_t)session_id);
                if (result)
                        result = ds_ipc_message_send (&success_message, stream);
                ds_ipc_message_fini (&success_message);
        }
        return result;
}

where as ds_ipc_message_initialize_header_uint64_t_payload is

bool
ds_ipc_message_initialize_header_uint64_t_payload (
        DiagnosticsIpcMessage *message,
        const DiagnosticsIpcHeader *header,
        uint64_t payload)
{
        EP_ASSERT (message);
        EP_ASSERT (header);

        message->header = *header;
        payload = ep_rt_val_uint64_t (payload);
        return ipc_message_flatten_blitable_type (message, (uint8_t *)&payload, sizeof (payload));
}

note ds_ipc_message_initialize_header_uint64_t_payload is used by eventpipe_protocol_helper_send_start_tracing_success which actually sends session_id allocated in little endian order fashion to dotnet-gcdump.

[mdh1418]

then this would parse incorrect session_id value to ipc stream

I thought we would need to pass in the corrected session_id back to eventpipe_protocol_helper_send_stop_tracing_success.

Both eventpipe_protocol_helper_send_(start|stop)_tracing_success call ep_rt_val_uint64_t on the correct host session_id. So if we need to correct the value passed over the wire, we should pass the corrected value through eventpipe_protocol_helper_send_stop_tracing_success

e.g.
Host Session ID = 0x1122334455667788
eventpipe_protocol_helper_send_start_tracing_success passes LE (0x1122334455667788) over the wire which on s390x would be 0x8877665544332211 and dotnet-gcdump decodes the wire bytes as little-endian as 0x1122334455667788

dotnet-gcdump then re-encodes to little-endian when sending Stop so it passes over the wire as 0x8877665544332211, and this PR is correcting with LE (0x8877665544332211) -> 0x1122334455667788
0x1122334455667788 matches the host session id and should also be passed through eventpipe_protocol_helper_send_stop_tracing_success to pass LE (0x1122334455667788) over the wire to dotnet-gcdump so it can again observe 0x8877665544332211

Currently, I don't think dotnet-gcdump validates the session_id, but we should still pass the same value into eventpipe_protocol_helper_send_stop_tracing_success that we pass into eventpipe_protocol_helper_send_start_tracing_success