https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95692
--- Comment #2 from Mark Allen ---
Hi, thanks for the input.
I was figuring gcc should see the inline assembly modifying r2
and any function call out of intercept_munmap() would be doing the
logical equivalent of saving the current r2, calling something
where a different r2 might be used, then upon return restoring
r2 to whatever it was when it left intercept_munmap().
But it sounds like you're saying gcc should be the exclusive
manager of r2. And I get that the activity of making a function
call isn't always going to be as linear as "save current r2,
set r2 for whatever new context it's calling into, restore r2".
I'm open to other solutions. For most alternatives I can think
of, I can at least imagine potential gcc behavior that would
conflict with us hacking r2, which I expect is why you're
suggesting doing nothing but our own assembly from
intercept_munmap() downward.
That would be rough though, we'd definitely like to be able to
call other functions from intercept_munmap().
The problem starts when we turn munmap into a branch into
intercept_munmap. At that point r2 would have been set up as
valid for munmap() but then we branched into intercept_munmap()
which presumably needs its own r2.
So far the best hack I can see is to put it all in the
initial branch. Eg overwrite munmap not just with a branch to
intercept_munmap, but replace r2 at that level (rather than at
the start of intercept_munmap). That essentially puts both of the
things that hack the state into the same location, after which
the state is consistent for gcc to continue doing whatever it
wants.
I'm getting the impression this isn't going to receive a
blessing as a "good" solution though. Any other ideas for
a "least bad" solution if we want to be able to make function
calls into other gcc-compiled functions from inside
intercept_munmap()?
