Re: VM as target, was Is Assembler Language essential

"George Neuner" <gneuner2@comcast.net> wrote in message
> On Sat, 21 Feb 2009 05:38:11 +1000, "cr88192" <cr88192@hotmail.com>
> wrote:
>
>>a related issue is that, my code can be linked with code produced by GCC
>>(or
>>MSVC, which has something similar), and GCC has this issue: many people
>>think it good practice to compile code with '-fomit-frame-pointer', which
>>may, technically, break some assumptions that could be made by my compiler
>>(such as if directly implementing exception unwinding, ...), and sadly, is
>>common practice within many of the system APIs (as evidenced by gdb's
>>inability to produce backtraces, ...).
>
> Whether it's a "good practice" is arguable, but omitting the frame
> pointer increases function call speed, slightly reduces stack usage
> and provides another general address register to use.


yes, but at a reasonable cost?...




> Stack tracing can be done without a frame pointer ... the debugger
> knows the function call sequence and the compiler's debug information
> provides the argument and local variable layout at function entry and
> may also incrementally provide info on other automatic variables at
> entry into local subscopes. From that starting point the debugger has
> to track the code position and monitor the stack pointer to build up a
> picture of what's currently on the stack. GDB doesn't do it.
>


Yes, it is possible to backtrace, for example, by locating the return IP,
and then getting back to that function and locating the next return IP, ...
but this requires keeping precise debugging information, and is likely to be
both far more complicated and more computationally expensive than using the
frame pointer for backtracing.


Win64 involves an "interesting" approach to this problem, namely that they
define the structure of the entry and exit points for functions, and so it
is possible for the debugger/... to scan forwards and locate the exit point
for the function, which gives the info needed to properly unwind from the
function (but, alas, this is not possible on x86).




I am still torn some between using SEH on Win32, or implementing my own
exception handling (technically, even if I do use my own handling, it would
be possible to hook into SEH and still catch and redispatch exceptions if
needed, although this would not have correct ordering/... if mixing my code
with that produced by MSVC).


however, SEH raises hairy issues, such as:
my compiler will have to know up front whether it is compiling for Win32 or
Linux (this is currently not known, but could be added);
SEH is fairly generic, but this makes exception handling a more complex
issue;
...


I may look into it more (possibly look into how g++ handles it, ...).


probably though, mine could be sort of like SEH, but specify a little more
semantics.
the alternative approach is to use backtracing and metadata, which is what I
had considered at first, but the frame-pointer issue may not allow this
(instead requiring TLS-based chaining).


luckily, I added built in support for TLS, but with a few sad restrictions:
currently will not be very efficient on Linux (main issue is that these
things are not well defined, and have apparently been changed around several
times in the not too distant past, so I have to do a pushad/popad and call a
generic TLS function, which is expensive...);
x86-64 is not currently handled (either Win64 or Linux).


on Win32, it requires a call to a thunk which consists of 2 or 3 mov
instructions (depending on the Win32 TLS index, as 0-63 require 2 mov's but
63-1087 require 3). this thunk is automatically generated by the dynamic
linker.


TLS support was integrated into the support for globals and static
variables, and so is fairly transparent.




note that if I use frame-pointer backtracing, there is no need for TLS (or
handler registration and unregistering) in exception handling, that or I
will have to figure out an alternative approach to backtracing which does
not rely on the frame pointer (or other info which may not be available with
hetrogeneous code...). it is just a big ugly mess that code from potentially
3 (or more) compilers all has to cooperate at the same time, limiting the
level of control and also that of the amount of available information...


it is not really clear which path is best...




meanwhile, I had started beating together a C# frontend, or thus far, at
least parts of the parser...
this requires resolving many uncertainties WRT the implementation
strategy...

Return to the comp.compilers page.
Search the comp.compilers archives again.