mps icon indicating copy to clipboard operation
mps copied to clipboard

Fix register scanning on FreeBSD and Linux

Open gareth-rees opened this issue 5 years ago • 4 comments

Restore assembly code (removed in change 194595 / commit 76166b7cf) for spilling callee-save registers on FR and LI platforms.

Fixes job004158 (Register scanning approach is not reliable)

gareth-rees avatar Sep 01 '20 09:09 gareth-rees

@UNAA008 @NickBarnes Any thoughts on this pull request? It has been open since June 2019, it would be nice to make some progress.

gareth-rees avatar Dec 31 '20 17:12 gareth-rees

In his original message, Filip Strömbäck writes:

When I compile the provided sample with -O3, the compiler does not use the rbp register for a frame pointer, but rather uses it to store local variables, in this case the variable "b".

I have a few questions.

  1. Are we sure this issue could apply to -O2 and below?
  2. Are we sure that design.stack-scan.sol.setjmp.justify is invalid by the standard?
  3. Do/can we support -O3 or even have a sensible policy about that any more?

I ask because removing assembler was quite a win, and we should not give it up lightly.

Relevant:

  • Clang optimisation levels https://stackoverflow.com/questions/15548023/clang-optimization-levels
  • GCC optimisation levels https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

rptb1 avatar Jan 10 '21 11:01 rptb1

I just saw the latest answer to this PR, I'm sorry for being slow in getting back to you.

  1. I am fairly sure that the compiler utilizes ebp for other things even at -O2, or even lower levels. In a separate project (Pintos if you have seen it), I needed to explicitly add the -fno-omit-frame-pointer to avoid this issue, even if we do not run at any major optimization level. That was on x86 though, not x86-64 which has more registers. From your linked optimization levels, it seems like -fomit-frame-pointer is at -O1 in GCC.
  2. This observation was based on me digging around inside the implementation of setjmp and longjmp (it was either in libbacktrace or parts of the GCC standard library). This implementation relied on the DWARF unwind tables to recreate most information inside the jmp_buf, so it only needed to store the program counter in there essentially. From a quick search, it seems like the contents of jmp_buf is not specified.

I can investigate closer if you want. I just need to find the details I wrote down at the time.

fstromback avatar Sep 18 '21 12:09 fstromback

See also https://github.com/Ravenbrook/mps/pull/151#issuecomment-1428492095

rptb1 avatar Feb 13 '23 19:02 rptb1