On Fri, 09 Nov 2007 21:02:39 +0000, Orchid XP v7 wrote:

> 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. ;-)

No, the final executable *needs* to know this.  You may lose the variable 
name, but the pointer from the variable itself to a memory location is 
something the program *must* know.

>> 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.

Actually, I am being real - it doesn't take a super-hyper-nerd to do what 
I'm describing.  It requires a bit of a background in software 
development and coding and knowledge of how the systems actually work.

Software engineers do this sort of thing every day - it's part of the job 
description.

>> 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...)

Technically it is impressive to be able to do that (especially if you've 
never seen it done before) - but the tools make it very very easy to do.  
I've taken cores and pulled stack traces and variables data out of them 
and compared to stacks in source code using tools like Source Navigator, 
which can give you detailed information about various functions including 
a way of looking at the call stacks so you can see what's going on as you 
step through the program.  Very easy to use, and very useful for this 
type of debugging.

I took a crash file from a system and combined with the use of SN, I was 
able to pinpoint *exactly* what changed in the code that caused the crash 
(comparing old version to new version) and submitted a patch.  Turned out 
the engineer had fixed it the day prior to my analysis, but my proposed 
fix was what he did to fix it.  That I came to the same conclusion using 
these tools as the guy who originally wrote the code should tell you 
something about the feasibility of using tools like this to accomplish 
this sort of task.  It all started with a core file.

Jim

Post a reply to this message