Re: Violations of mandatory MISRA C:2012 Rule 19.1 in X86_64 build

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.07.2023 18:40, Roberto Bagnara wrote:
> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
> overlapping object) is directly targeted at two undefined behaviors,
> one of which is the subject of 6.5.16.1p3, namely:
> 
>    If the value being stored in an object is read from another object
>    that overlaps in any way the storage of the first object, then the
>    overlap shall be exact and the two objects shall have qualified or
>    unqualified versions of a compatible type; otherwise, the behavior
>    is undefined.
> 
> You can see a number of definite violations in the X86_64 build
> at this link:
> 
>    
> https://saas.eclairit.com:3787/fs/var/local/eclair/XEN.ecdf/ECLAIR_normal/origin/staging/X86_64-Set1/149/PROJECT.ecd;/by_service/MC3R1.R19.1.html

Just to summarize: Except for one instance, all follow the same pattern
of extending in-place a (guest) register value. Sometimes in straight
line code (typically eip -> rip), otherwise in get_rep_prefix() (esi ->
rsi and edi -> rdi). I continue to think that the way we have it is the
best way for it to be written; as per an earlier reply I also can't see
how even a "malicious" compiler (still aiming at generating correct
code, just not necessarily doing things the "obvious" way) could break
those cases. (I understand none of this is going to help, yet I'd like
to clarify that sometimes overly strict rules are getting in the way,
like here forcing use to e.g. switch to using casts when we'd like to
avoid doing so.)

The one other instance is in compat multicall handling. There I guess
the compiler could indeed do things "the wrong way". Any solution there
that I can think of would involve an auxiliary on-stack array, to first
copy into and then out of. That's not very efficient, so I wonder what
your suggestion would be how to deal with such a case.

Jan