casey@CS.UCLA.EDU (09/01/88)
Ok, I just don't understand what's going on here. If I do an nm(1) against an object, it tells me that the variable XXXfoo has been assigned location 0. When I start up dbx against the object (and run it telling it to stop in main so I can look at things), dbx says that the address of XXXfoo (&XXXfoo) is now 0xac5e0. I can deal with that. Things just get mapping into memory when an object is loaded. And when I use /com/debug -smap, it tells me about this mapping. So that's cool. Now I continue executing up to the fault in xmh that I'm trying to track down. Now when I ask it to print out the addresses of variables, it gives me random values. It's almost as if the debugger itself has become corrupted. The values aren't consistent in any way. Two variables which used to be adjacent to each other are now indicated as being 16Kb apart. The question that comes to my mind here is as follows: when I look at the contents of the address first given for variable when I stopped it in main, it has the right value at the fault, even though dbx is now telling me that the variable has a different address. I had thought that the variable was getting trashed, but now it appears not. Could it be that the processes mapping is being corrupted? I guess my next attempt will be to try to cross process debug this so that the debugger itself doesn't get clobbered. Casey
pato@apollo.COM (chc 02 rd) (09/03/88)
In article <15689@shemp.CS.UCLA.EDU> casey@CS.UCLA.EDU (Casey Leedom) writes: > > Ok, I just don't understand what's going on here. If I do an nm(1) >against an object, it tells me that the variable XXXfoo has been assigned >location 0. When I start up dbx against the object (and run it telling >it to stop in main so I can look at things), dbx says that the address of >XXXfoo (&XXXfoo) is now 0xac5e0. I can deal with that. Things just get >mapping into memory when an object is loaded. And when I use /com/debug >-smap, it tells me about this mapping. Before sr10 most programs are compiled into position independent code (PIC). nm cannot give you accurate addresses, only relative addresses. Symbols are only given absolute addresses at load time. > > So that's cool. Now I continue executing up to the fault in xmh that >I'm trying to track down. Now when I ask it to print out the addresses >of variables, it gives me random values. It's almost as if the debugger >itself has become corrupted. The values aren't consistent in any way. >Two variables which used to be adjacent to each other are now indicated as >being 16Kb apart. > > The question that comes to my mind here is as follows: when I look at >the contents of the address first given for variable when I stopped it in >main, it has the right value at the fault, even though dbx is now telling >me that the variable has a different address. I had thought that the >variable was getting trashed, but now it appears not. Could it be that >the processes mapping is being corrupted? > This can happen for a variety of reasons. 1) the address of a global variable may be derived relative to the "db" register. In this case, referencing the address of that variable from a module that does not have the symbol in its scope will yield undefined results. The db register is pointing to a block that does not have a valid address for this symbol (This behavior is documented in the /com/debug manual - which describes various addressing modes used by the compiler. I don't have a 9.7 manual in front of me, but the DBX man page used to refer to the /com/debug manual.) 2) Some variables spend some portion of their lifespan in registers (through compiler optimizations). Examining the variable after it is no longer being used may not provide useful information. (i.e., if the optimizer decides that a variable is no longer needed, it may not ever transfer the final value from its register location to its memory location. Examining the variable after you have left the runtime scope that the compiler has constructed - even though you are still in the correct lexical scope - may be misleading) At sr9.7 you can use the undocumented berkeley dbx command "psym <symname>" to get information about the addressing mode (and register assignments) for variables. This may help you understand the values being printed by DBX. > I guess my next attempt will be to try to cross process debug this so >that the debugger itself doesn't get clobbered. > DBX is always "cross process debugging" the target program. It uses ptrace() to control the child process which is running the target program. The target program does not run in the same process/address space as DBX, and therefore cannot be corrupting the debugger. >Casey
casey@admin.cognet.ucla.edu (Casey Leedom) (09/06/88)
Joe Pato, Thanks for the notes about how objects are loaded in memory. The reference to the "db" register and module symbol scopes should be especially helpful. I'll probably just wait for SR10 before I continue working on xmh. Ralph Swick tells me that this is the first such complaint about xmh, so it's probably just an SR9.7 bug. Still waiting desperately for SR10, Casey