Jim Henderson wrote:

> Part of the contents of a program in memory is a symbol table - which is 
> a table that basically tells you what data is stored where.  After all, 
> the program has to know where the value for a variable called "a" is 
> stored, which means that can be figured out.

Now, see, I was told the purpose of a "linker" is to elide all such data 
before building the final executable. ;-)

> So what you do, working at a machine level, is start with where EIP is 
> and work backwards.  You look at the stack backtrace to see what 
> functions called what functions, and you can figure out what code path 
> the program had taken.

Yeah, but let's be real here. The actual generated machine code is going 
to bear *no relationship* to the original program source code. Only a 
super-hyper-nerd is ever going to get anything useful out of it.

> From a code standpoint, using Borland C++ (years ago), there was a source-
> level debugger that you could single step through.  IIRC, there was a way 
> to take data from a crashed program and use it as well, but it's been a 
> long time since I did that.

That's impressive. Usually these things work by inserting software 
interrupts into the code. (Or just software enumation of machine state...)

Post a reply to this message