importing symbols from unsupported BFD target

importing symbols from unsupported BFD target

[Tavis Ormandy]

Hello, I'm trying to setup remote debugging of a partially supported BFD
target. Accessing the target via a GDB stub works perfectly, and I can
examine memory, set breakpoints, etc, but I'm stuck without symbols as BFD
cannot read the symbol table from the input file.

I feel pretty close to getting this working, but I must be missing a minor
detail.

So on the unsupported target system using the native vendor-provided tools,
I export a list of symbols, their (approximate) sizes, and absolute
addresses. Now I need to make gdb understand these, so my first thought was
trying to create a relocatable ELF with a bunch of abs sym definitions and
loading it via symbol-file (I'm happy without type information and so on for
now).

This basically works, `info address symname`, `b symname`, `x/i symname` all
work, but `info symbol address` fails, and stacktraces, info breakpoints,
etc, etc are not symbolised.

Can anyone suggest what I might be missing?

Thanks, Tavis.

Some more detailed information:

The target system is Windows, and I'm trying to debug a kernel issue from a
Linux x86 host using the VMWare GDB guest stub.

So on the guest I can create a list of symbols and convert them into
gas-style absolute symbol declarations:

$ kd -z c:\\windows\\memory.dmp -c 'x /a nt!*;q' \
    | bash kd2as.sh > ntoskrnlsyms.s

This command generates a list of declarations from the vendor's native
debugger output, the result looks like this:

...
.global NtCreateFile
.set    NtCreateFile, 0x8056e2fc
.size   NtCreateFile, 426
.type   NtCreateFile, @function
.func   NtCreateFile
.endfunc
.global NtCreateNamedPipeFile
.set    NtCreateNamedPipeFile, 0x8056e336
.size   NtCreateNamedPipeFile, 58
.type   NtCreateNamedPipeFile, @function
.func   NtCreateNamedPipeFile
.endfunc
...

Currently i mark all symbols as STT_FUNC, which is fine for now, and i can
assemble it on Linux, which generates symbols like so:

$ as -gstabs+ -o ntoskrnlsyms.o ntoskrnlsyms.s
$ readelf --syms ntoskrnlsyms.o  | grep NtCreateFile
  4993: 8056e2fc   426 FUNC    GLOBAL DEFAULT  ABS NtCreateFile

gdb accepts it, and it works:

$ gdb -q
(gdb) show version 
GNU gdb Fedora (6.8-27.el5)
(gdb) target remote localhost:8832
[New Thread 1]
0x806d0d34 in ?? ()
(gdb) symbol-file ntoskrnlsyms.o 
(gdb) info address NtCreateFile
Symbol "NtCreateFile" is a function at address 0x8056e2fc.
(gdb) x/2i NtCreateFile
0x8056e2fc:     mov    edi,edi
0x8056e2fe:     push   ebp
(gdb) b NtCreateFile
Breakpoint 1 at 0x8056e301

etc, etc, however:

(gdb) info symbol 0x8056e2fc
No symbol matches 0x8056e2fc.
(gdb) bt
#0  0x8056e301 in ?? ()
#1  0xedb88b44 in ?? ()
#2  0x8053d648 in ?? ()
...

Which is limiting the usefulness of having symbols, if anyone can spot the
problem I'd really appreciate a pointer.

Thanks, Tavis.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my pgp key.
-------------------------------------------------------

Re: importing symbols from unsupported BFD target

[Daniel Jacobowitz]

On Tue, Jun 30, 2009 at 06:59:06PM +0200, Tavis Ormandy wrote:
> This basically works, `info address symname`, `b symname`, `x/i symname` all
> work, but `info symbol address` fails, and stacktraces, info breakpoints,
> etc, etc are not symbolised.
> 
> Can anyone suggest what I might be missing?

I think you're going to have to create sections in the file; this
sounds like it's going to be specific to ABS symbols.  A NOBITS
(bss) section is probably fine though it may need to be marked
executable too.

-- 
Daniel Jacobowitz
CodeSourcery

Re: importing symbols from unsupported BFD target

[Tavis Ormandy]

Daniel Jacobowitz <drow@false.org> wrote:

> On Tue, Jun 30, 2009 at 06:59:06PM +0200, Tavis Ormandy wrote:
> > This basically works, `info address symname`, `b symname`, `x/i symname`
> > all work, but `info symbol address` fails, and stacktraces, info
> > breakpoints, etc, etc are not symbolised.
> > 
> > Can anyone suggest what I might be missing?
> 
> I think you're going to have to create sections in the file; this sounds
> like it's going to be specific to ABS symbols.  A NOBITS (bss) section is
> probably fine though it may need to be marked executable too.
> 

Ahh, you were absolutely right :-)

It took some massaging to convince ld to create the output I wanted, but it
does appear to have worked, and I can now do basic remote debugging of the
windows kernel using gdb.

And the backtrace is now symbolised correctly:

Breakpoint 23, 0x805c517d in PsImpersonateClient ()
(gdb) bt
#0  0x805c517d in PsImpersonateClient ()
#1  0x805ece9b in SeImpersonateClientEx ()
#2  0x8059a68a in NtImpersonateClientOfPort ()
#3  0xee392c01 in ?? ()
...

Which looks exactly right. Really pleased I can work on this from within
gdb.

Thanks, Tavis.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my pgp key.
-------------------------------------------------------