Re: Does a function know where it was called from?
On Sep 9, 5:49 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:b2859b89-9e53-4611-bed0-99e4e8d0343e@k30g2000vbn.googlegroups.com...
On Sep 8, 11:08 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
"Victor Bazarov" <v.baza...@comcast.invalid> wrote in message
[...]
in both of the above systems, things like exceptions are
usually handled by creating and linking together temporary
exception frames, and jumping from one frame to another. this
works for exceptions, but doesn't itself facilitate doing
a backtrace.
Why would a compiler do something stupid like that? Most
compilers, I think, just generate blocks of static data, which
the exception handling evaluates, rather than doing anything
dynamically before there is an exception.
on Win-32, this is SEH, which is generally used for exceptions...
SEH basically works be creating temporary exception frames on
the stack, and linking them together (via a linked list stored
in the TEB, which is basically a special structure which
manages thread-local-variables and similar). on returning
through functions these frames are unlinked.
so, for example, every "try {}" block will involve linking and
unlinking some state, and throwing an exception will involve
stepping along this linked list calling handlers until one
"bites"...
Does this include the "implicit" try blocks, which occur every
time you define a local object which has a non-trivial
destructor (which has to be called when unwinding the stack).
If so, it's about the worst imaginable implementation of
exceptions.
Win64 devised a very different way of doing exceptions (still
called SEH though), where the ability to both perform
backtraces and unwind for exceptions is built right into the
ABI, and does not involve any separate linked-list structure
(exception handlers can be instead registered for regions of
code).
this involves both the use of pattern matching on machine-code
(formed according to specific rules) and table-like structures
embedded into the compiled code.
The "best existing practice" would put the tables in a separate
segment, so that they would be in different pages than the usual
executable, and only be paged in if an exception was thrown.
(But as far as I know, not many compilers actually go this far;
most generate the tables next to the code.
there is also VEH on WinXP and newer, ...
on Linux, there are several different exception handling
libraries, some working similar to SEH.
I am not sure what GCC uses, as I couldn't find any solid
info. some information pointed in the direction of libunwind,
but nothing solid was found.
I've not looked lately, but in the past, I think g++ generated
static tables, mapping address ranges to a cleanup handler. The
exception handling routine walked the stack back, looking up
each return address in the tables, and calling the cleanup
handler if it found it. I was under the impression that this
was standard practice; it seems like the obvious solution (and
entails no runtime overhead unless an exception is thrown).
[...]
for Linux, part of the functionality can be gained via libdl
(Linux provides some non-POSIX extensions), and via libunwind.
I've got code which works for Linux on Intel (32 bit) and for
Sparc (obviously, not the same code). All it does, however, is
acquire the return address and save it (as binary data);
conversion to symbolic form is left to the user (and isn't
possible without some sort of map, or if the executable has been
stripped). The GNU binary utilities library (normally installed
under Linux, but available for other systems as well) has
a program called addr2line, which can be used to obtain the
source filename and linenumber and the name of the function;
under Unix, you may also be able to get the information you need
with nm.
yes, this can be done.
however, I was also considering the more general matter of backtraces.
My code does a backtrace. (I use it in debug versions of
operator new, to save the context in which the memory was
allocated.)
luckily, most (non-optimized) code still contains frame-pointers, so
backtraces tend to work.
I've not looked at the problem for awhile now; back when I did,
even optimized code had frame-pointers, except in leaf functions
(which didn't call any other function). And leaf functions
weren't an issue for me, since I was only interested in the
backtrace in functions which called my operator new or operator
delete function (which I did compile without optimization, and
with other special options to ensure that I got something
consistent and usable).
And I don't think I've ever used this code in optimized code, so
even if more modern compilers do suppress frame pointers in
optimized code, I wouldn't have noticed it.
--
James Kanze