"James Van Buskirk" <not_valid@[EMAIL PROTECTED]
> wrote in message
news:yLGdnReybdwp_ZbVnZ2dnUVZ_vOdnZ2d@[EMAIL PROTECTED]
> These are what I came up with via reverse engineering
> gfortran assembly language output.
Oh yeah, another thing I noticed from the assembly language code
was that if you compiled with the -fomit-frame-pointer switch the
compiler generated code that accessed at negative offsets from rsp.
I'm sure the gcc guys have been around he block on this one several
times already, but is it really safe to do this? In SWConventions.doc
that comes with the Windows SDK, it says:
"First, all memory beyond the current address of RSP is considered
volatile: The OS, or a debugger, may overwrite this memory during
a user debug session, or an interrupt handler. Thus, RSP must
always be set before attempting to read or write values to a stack
frame."
The same verbiage may be found at
http://msdn2.microsoft.com/en-us/library/x4ea06t0(VS.80).aspx
.
This is not the case in Linux where there is a 128-byte red zone
below rsp, according to Agner Fog. Now going to
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fomit_002dframe_002dpointer-592
it is do***ented that -fomit-frame-pointer makes debugging
impossible on some machines, so this covers one rationale for
Microsoft's proscription on gcc's usage, and the other rationale
seems dubious as well because the current task's context should
be saved in its TSS or some other place than its ring-3 stack,
and it would be senseless for ring-0 code such as an interrupt
handler to assume that a ring-3 stack has any space left to
safely write to.
Even so, writing to negative offsets from rsp seems to be contrary
to Microsoft's do***entation, so has someone at gcc taken this up
with Microsoft and made sure that it's OK?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
|
