Bug 69530

in which cases is our vcpu state not fully up to date?

are you referring to the incip hack?

Generated code normally only stores the register state back into the baseblock at the end of each basic block.  If one of the instructions in the basic block has an exception the VCPU state will not have been updated.  If that exception's signal is caught, the handler will not see up to date state, and returning from the handler would try to restart the instruction with the wrong state.

Delayed update of the VCPU's EIP would also be a problem.

Since saving all the state back before each potentially exception-causing instruction could get expensive, this should probably be a CLO, and/or controllable by client requests.

Bug 74298 is an example of this hitting us in practice.

The general workaround for any code which needs precise exceptions is to use --single-step=yes.  This treats every instruction as an independent basic block.  I would expect this to have a pretty significant performance hit.

How about this:

First of all, don't change your codegen in any way.  When somebody registers a signal handler using sigaction(), register your own wrapper signal handler instead.  It does:
1. Update the VCPU's state using the context you receive from the kernel.
2. Call the user's signal handler with the VCPU's (now correct) context.
3. Restore the VCPU's state from whatever the user handed back to us.

I realize that since I've no clue about the internal workings of Valgrind, this may or may not be useful in any way, so I promise not to whine if you tell me the idea sucks :-).

The reason for intercepting only sigaction() is that sigaction() is the only way to register a signal handler that receives a CPU context to play with.

The problem is that the virtual CPU state is completely, well, virtual.  At any given instruction, we don't record where the value of, say, virtual EAX currently resides, so we don't know where to pick it up from (it almost certainly isn't in the real EAX).  At the end of each basic block, we do return all the registers to well-known places, so the state is in sync then.

This only applies to signals which hit in the middle of a basic block, which limits it to synchronous exception signals (ie, SIGSEGV, SIGBUS, SIGFPE and SIGILL caused by instructions).  Async signals are all blocked, and are only processed at context switch time, which means we're definitely not in the middle of a basic block.

In that case, you'll need to synch before every faulting instruction just as you said.  It could have worked though :-).

Is this still needed?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!

Undoing KDE robot brain damage.