In D143248#4199929, @asb wrote:

In D143248#4128698, @varunkumare99 wrote:

In D143248#4122933, @asb wrote:

Hi Varun - thanks for filing bug #60698 to help track this issue, and for noticing that there should now be some upstream support for cfi_remember_state and cfi_restore_state.

The first question that comes to my mind is what degree of testing you've done with this?

Hi Alex,
the patch updates over 500 testcases for RISCV(as it adds cfi info the epilogue), which results in a patch of over 30M. Due to which I'm not able to upload.

In D143248#4128698, @varunkumare99 wrote:

In D143248#4122933, @asb wrote:

Hi Varun - thanks for filing bug #60698 to help track this issue, and for noticing that there should now be some upstream support for cfi_remember_state and cfi_restore_state.

The first question that comes to my mind is what degree of testing you've done with this?

Hi Alex,
the patch updates over 500 testcases for RISCV(as it adds cfi info the epilogue), which results in a patch of over 30M. Due to which I'm not able to upload.

Sorry for not getting back on this. I was thinking more about real-world testing rather than just test case changes.

In D143248#4131555, @shiva0217 wrote:

Hi Varun,

It might be good to have a simple case to illustrate that cfi_remember_state and cfi_restore_state can be generated properly with epilogue CFI.
For examle, could the following case generated with cfi_remember_state and cfi_restore_state as GCC?

extern void foo(void);
void f(int *i) {
  if (*i == 0) {
    *i = 1;
    foo();
    return;
  } else {
    __builtin_printf("Hi");
    *i=0;
  }
}

This patch emits cfi_same_value directives when the unwind table needs to be reset to the initial one.
By default emission unwind tables is disabled for RISC-V.
Need to pass -fasynchronous-unwind-tables to emit unwind tables.

In D143248#4122933, @asb wrote:

Hi Varun - thanks for filing bug #60698 to help track this issue, and for noticing that there should now be some upstream support for cfi_remember_state and cfi_restore_state.

The first question that comes to my mind is what degree of testing you've done with this?

In D136462#3878895, @DavidSpickett wrote:

I agree that this change names - print - restore names is going to cause problems. Pavel is right that this should happen in some dump function somewhere.

But, assuming what you've got works to an extent, you should add some testing first. That will allow you to refactor with less risk. You'll be able to reuse a lot of the tests later, so it's not wasted effort and it'll flush out some corner cases you haven't thought of.

In D136462#3878682, @labath wrote:

This is definitely not a good way to implement this functionality. There's no telling who else might be accessing the symbols while their names are being changed.

The colouration should be implemented inside the dumping function, without modifying the state of the debugger. I realize that's not currently easy to do, but that's not a reason to do this. It's possible the dumping machinery needs to be refactored to support this kind of customized colouration.