| Re: [cdt-dev] Source/address lookup in objectfile |
Hi Torleif, I too have recently been trying to convert addresses to source code locations, or at least function names. Here's some code which might help: CDebugTarget target = .... IAddress add = target.getDisassembly().getAddressFactory().createAddress(Long.toString(address)); ICStackFrame f = new FakeStackFrame(add); // class which just returns the address given to it IDisassemblyBlock block = target.getDisassembly().getDisassemblyBlock(f); IAsmSourceLine[] lines = block.getSourceLines(); if (lines.length == 0) throw new Exception("No lines of assembly returned"); IAsmInstruction[] insts = lines[0].getInstructions(); if (insts.length == 0) throw new Exception("No instructions returned"); return insts[0].getFunctionName(); In my case it didn't work. The IAsmInstructions are populated by the debugger layer, but in my case, they didn't get the function name filled in by the underlying debugger (when queried by address). However, perhaps your debugger works differently. Although, I don't think you can get the source code location out of an IAsmInstruction, but perhaps you can look up the symbol name somehow once you've got it. The other approach I tried was to discover the load address of each DLL, calculate the offset into the DLL and use the likes of IBinaryParser to work out the symbol based on that offset. That didn't work out for me, since the binary parsers don't fully understand the symbolic information inside my binaries I'm using, despite some useful additions by Nokia. In any case you'd need to use some out-of-band method to discover the load address of each DLL since I haven't found a way to query the debugger for that information. However, if you could get this to work, the returned ISymbol would contain function names, source code locations etc. I also looked into the GDB/MI commands -symbol-info-symbol (which appears to be unimplemented even in GDB, let alone Eclipse) and -var-evaluate-_expression_ (which doesn't appear to return a type name, despite the 'x' GDB command doing so). In summary: I haven't found a way to do this using Eclipse APIs. I'm now using Microsoft's dbghelp.dll library to obtain the information I need. But maybe that disassembly trick might work for you. Good luck! Let me know if you find a way to get it to work nicely. Cheers Adrian On 11 Jan 2007, at 08:25, Torleif Sandnes wrote:
|