I''l give that a shot. Thanks
On 1/25/07, Mike Stump <[EMAIL PROTECTED]> wrote:
On Jan 25, 2007, at 2:11 PM, Jason Erickson wrote:
> I'm working on a project where every so often one of our games comes
> back and we pull the ram off the game for saving, and sometimes for
> anaylisis. Currently the only varibles in ram that we can physically
> look at are the static members. The information that we would love to
> get to is the heap memory and be able to know what dynamically
> allocated structure that heap memory belongs to.
Heap objects can be found by looking at stack and global variables.
> What I need to know, is there some way to read the binary with some
> program to figure out which order everything in memory is being
> allocated, so that I can write a program to read the memory dump and
> figure out which memory locations belong to which pointer varibles.
> Our code is written in C with litteraly tons of pointers. It runs on
> the i960 processor (yeah I know...soo old...but it works and it costs
> a lot of money to change once its been approved).
>
> Any ideas would be appricated to be able to read the binary to figure
> out the order in which varibles get loaded onto the heap.
First, wrong list. gcc-help is closer, but that is for compiler
help. Your question really has little to do with the compiler, but
rather, debugging. You could create a gdb remote stub for your game
and then just fire up gdb with the `core file'. Assumes that you've
enhanced gdb to read your core files. You can save off the -g built
game and point the debugger at that code. You then debug any data
structures you want, using gdb. If you just want a memory map, see
the ld documentation.
If you're question is how do I write a debugger, please, don't do
that, just reuse gdb. It supports remote debugging and i960s just fine.
--
Jennys Website
http://www.dontbflat.com
