making stabs visible to gdb

making stabs visible to gdb

[Tavis Ormandy]

Hello, I have a stripped binary I don't have the source for that I would
like to debug in gdb. I thought writing some .stabs statements in gas
would be a nice easy way to record the symbols I know about, like this:

.equ N_FUN, 0x24
.equ N_PSYM, 0xa0
.stabs "example:f-11", N_FUN, 0, 0, 0x8005bba
.stabs "foo:p*-8", N_PSYM, 0, 0, 8
.stabs "bar:p-10", N_PSYM, 0, 0, 12

https://sourceware.org/binutils/docs/as/Stab.html

I think this describes a function like this at address 0x8005bba:

void example(unsigned int *foo, unsigned long bar)

If I assemble that (as -gstabs), then add-symbol-file a.out, gdb knows
about it but won't resolve it in backtraces.

(gdb) add-symbol-file a.out
(gdb) info address example
Symbol "example" is a function at address 0x8005bba.
(gdb) pt example
type = void (unsigned int *, unsigned long)
(gdb) bt
..
#1  0x0000000008005bba in ?? ()     <-- unresolved
..

What am I doing wrong?

Also, is there a better way to accomplish what I'm trying to do?

Tavis.

-- 
 _o)            $ lynx lock.cmpxchg8b.com
 /\\  _o)  _o)  $ finger taviso@sdf.org
_\_V _( ) _( )  @taviso

Re: making stabs visible to gdb

[Nick Clifton]

Hi Tavis,

> Hello, I have a stripped binary I don't have the source for that I would
> like to debug in gdb. I thought writing some .stabs statements in gas
> would be a nice easy way to record the symbols I know about, like this:
> 
> .equ N_FUN, 0x24
> .equ N_PSYM, 0xa0
> .stabs "example:f-11", N_FUN, 0, 0, 0x8005bba
> .stabs "foo:p*-8", N_PSYM, 0, 0, 8
> .stabs "bar:p-10", N_PSYM, 0, 0, 12

If you assemble this and then run "objdump --debugging" on the resulting
object file (or linked executable), do you get the kind of output you
would expect, describing function "example" ?  If not, then this would
indicate that the stabs directives that you are using are wrong/incomplete.

> If I assemble that (as -gstabs), then add-symbol-file a.out, gdb knows
> about it but won't resolve it in backtraces.

You may find that asking this question on the gdb mailing list also helps.
Ie, it is possible that this is a gdb specific problem...

> What am I doing wrong?

My guess - you need to provide more stabs information.  Are you able to
compile a real C source file and capture the assembler output so that
you can compare the compiler generated stabs directives to your own ?

> Also, is there a better way to accomplish what I'm trying to do?

I don't think so.  There may be a gdb command that associates an address
with a symbol name, but I do not know what it is.  Sorry.

Cheers
   Nick

Re: making stabs visible to gdb

[Tom Tromey]

>> Also, is there a better way to accomplish what I'm trying to do?

In the gdb test suite, we have some Tcl code that makes it relatively
simple to create synthetic DWARF.  So, I'd consider extracting that and
using it to describe your program.

Nick> There may be a gdb command that associates an address
Nick> with a symbol name, but I do not know what it is.  Sorry.

There isn't one that does exactly this, but you can probably use the
'compile' command to achieve it.

Tom

Re: making stabs visible to gdb

[Tavis Ormandy]

On 2022-08-05, Tom Tromey wrote:
>>> Also, is there a better way to accomplish what I'm trying to do?
>
> In the gdb test suite, we have some Tcl code that makes it relatively
> simple to create synthetic DWARF.  So, I'd consider extracting that and
> using it to describe your program.
>

Hmm thanks, it kinda works - but it generates tons of warnings like
this:

warning: (Internal error: pc 0x8129250 in read in psymtab, but not in
symtab.)
warning: (Internal error: pc 0x8129250 in read in psymtab, but not in
symtab.)
warning: (Internal error: pc 0x8129250 in read in psymtab, but not in
symtab.)

It's so close to working nicely, but I think these warnings can't be hidden.

What do you think about removing that warning?

> Nick> There may be a gdb command that associates an address
> Nick> with a symbol name, but I do not know what it is.  Sorry.
>
> There isn't one that does exactly this, but you can probably use the
> 'compile' command to achieve it.
>

Do you have an example of what you had in mind?

I thought you might mean something like this, but I couldn't figure out
the details:

compile code -raw void (*example)(unsigned *foo, int bar) = (void*)(0x8005bba); void _gdb_expr(){};

Tavis.

-- 
 _o)            $ lynx lock.cmpxchg8b.com
 /\\  _o)  _o)  $ finger taviso@sdf.org
_\_V _( ) _( )  @taviso

Re: making stabs visible to gdb

[Tavis Ormandy]

On 2022-08-20, Tavis Ormandy via Binutils wrote:
> On 2022-08-05, Tom Tromey wrote:
>>>> Also, is there a better way to accomplish what I'm trying to do?
>>
>> In the gdb test suite, we have some Tcl code that makes it relatively
>> simple to create synthetic DWARF.  So, I'd consider extracting that and
>> using it to describe your program.
>>
>
> Hmm thanks, it kinda works - but it generates tons of warnings like
> this:
>
> warning: (Internal error: pc 0x8129250 in read in psymtab, but not in
> symtab.)

Nevermind, I figured it out - just making sure a matching section exists
that overlaps that region hides the warning.

This actually works really well, I made some gas macros to make the
syntax nice:

.include "symbols.s"

# bool rddec(char **numstr, uint16_t *num) @ 0x81dac90
function rddec, %bool, 0x81dac90
    param numstr, ** %char
    param num, * %uint16_t

It works perfectly:

(gdb) add-symbol-file symbols.dbg
(gdb) pt rddec
type = boolean (char **, unsigned short *)
(gdb) x/i rddec
0x81dac90 <rddec>:   push   ebp
(gdb) b rddec
Breakpoint 1 at 0x81dac96
(gdb) r

Even parameters work nicely:

Breakpoint 1, 0x081dac96 in rddec (numstr=0xffffc044, num=0x8350dbe)
(gdb) pt numstr
type = char **
(gdb) p *numstr
$1 = 0xffffc048 "06"

I'm really pleased with how this turned out, thanks for the hints!

Tavis.

-- 
 _o)            $ lynx lock.cmpxchg8b.com
 /\\  _o)  _o)  $ finger taviso@sdf.org
_\_V _( ) _( )  @taviso