target/riscv: support log memory access128

[zqb-all]

log_memory_access only support size 1/2/4/8, let write_memory_bus_v1 call log_memory_access multiple times to fix size assert fail.

Change-Id: I6b22c97f81fac26703b66d3dbd8b6d41aaea4875

[JanMatCodasip]

Hi @zqb-all, thank you for submittng this change.

My recommendation would be to implement this differently: extend log_memory_access() function to accept 128-bit values instead of calling it multiple times with smaller values. That's because one 128-bit memory access is a different thing than four 32-bit accesses - and the log messages should clearly reflect that.

Note: I understand it can be tricky to extend log_memory_access() to accept 128-bit inputs since support of 128-bit integer data types is not required by the C standard (1, 2). So you can create a second function log_memory_access128() that would accept an array as an argument.

Also, how have you tested these changes?

[zqb-all]

My recommendation would be to implement this differently: extend log_memory_access() function to accept 128-bit values instead of calling it multiple times with smaller values. That's because one 128-bit memory access is a different thing than four 32-bit accesses - and the log messages should clearly reflect that.

Thanks，I will modify patch in this way

Also, how have you tested these changes?

I have a riscv board with a cpu that supports sbaccess128，debug it with openocd and do some memory writes can trigger this assert

[zqb-all]

log show like this:

Debug: 28502 73591 riscv-013.c:2582 log_memory_access128(): M[0x40020f70] writes 0x0000001300000013b7ed56f580820141
Debug: 28503 73591 riscv-013.c:2582 log_memory_access128(): M[0x40020f80] writes 0x879700a7e86303f007930800e4221141
Debug: 28504 73592 riscv-013.c:2582 log_memory_access128(): M[0x40020f90] writes 0x80820141642276a7d00b0a2787930001

[JanMatCodasip]

I assume that function read_memory_bus_v1() would need the same update, is that correct?

If you do not wish to do it in this merge request, that is OK. In that case please create an issue so that this "TODO" item is recorded. The changes made so far are already nice improvement over the current state.

[zqb-all]

I assume that function read_memory_bus_v1() would need the same update, is that correct?

Yes, thank you for pointing that out

If you do not wish to do it in this merge request, that is OK. In that case please create an issue so that this "TODO" item is recorded. The changes made so far are already nice improvement over the current state.

After this patch is merged, I will submit another patch to update read_memory_bus_v1

[JanMatCodasip]

@zqb-all Thank you for the changes (and I'm sorry for my not so prompt reply).

It looks all right - approved.

[timsifive]

I'm not a fan of renaming a bunch of trigger variables in a commit that's about logging 128-bit memory accesses.

But the code looks OK.

[TommyMurphyTM1234]

I'm not a fan of renaming a bunch of trigger variables in a commit that's about logging 128-bit memory accesses.

But the code looks OK.

Would it make more sense to split it into two discrete PRs?

[zqb-all]

Would it make more sense to split it into two discrete PRs?

Thanks, next time there is a similar change, I will split it into a separate PR

[zqb-all]

I assume that function read_memory_bus_v1() would need the same update, is that correct?

If you do not wish to do it in this merge request, that is OK. In that case please create an issue so that this "TODO" item is recorded. The changes made so far are already nice improvement over the current state.

#833