Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Nov 1999 12:01:00 -0800
From:      "Ronald F. Guilmette" <rfg@monkeys.com>
To:        Marc Tardif <intmktg@CAM.ORG>
Cc:        freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG
Subject:   Re: disassembling syscalls 
Message-ID:  <66900.943646460@monkeys.com>
In-Reply-To: Your message of Fri, 26 Nov 1999 14:31:05 -0500. <Pine.LNX.4.10.9911261422280.13516-100000@Gloria.CAM.ORG> 

next in thread | previous in thread | raw e-mail | index | archive | help

In message <Pine.LNX.4.10.9911261422280.13516-100000@Gloria.CAM.ORG>, you wrote
:

>On FreeBSD 2.2.5 (I know I should change, but it works), gcc 2.7.2.1, gdb
>4.16, typing 'disassemble syscall_as_seen_in_main' I get:
>No function contains specified address.

What the heck is "syscall_as_seen_in_main"?

(Sorry if I'm ignorant, but I have no idea what that stands for.)

>Using the same procedure on FreeBSD 3.3-RELEASE, gcc 2.7.2.3, gdb 4.18, I
>get some output which is shorter than I expected, but I'll probably have
>to trace through more calls and branches.
>
>By the way, how can I trace names which start with a period?

What do you mean by ``trace''?

>they sometime
>appear when I type 'disassemble' followed by a tab, but typing the name
>with and without the period doesn't work either.

Symbols that begin with periods are used for various things, some of which
are NOT things that you can set breakpoints on (or disassemble, or whatever).

For example ELF *section names* (e.g. .text) begin with periods, but section
names are not things that you can set breakpoints on.

Some versions of gcc (for some targets) also create regular symbols which
begin with periods, but these are just so-called ``local'' symbols.  Depending
upon the assembler in use, they may or may not still be known in the binary
object files and/or in the final executable file.

If you have loaded something into gdb and then disassembled a part of it
and if you see some symbol in the disassembled code that begins with a
period, then you _may_ perhaps be able to get its address by just doing:

	print &.foo

(where `.foo' is the symbol), but then again, maybe not.  Actually, I think
that gdb will probably not allow you to do this because its built-in expression
parser only understands higher-level language syntax (e.g. for C and/or C++)
and in either C or C++, the expression &.foo has invalid syntax.

So you may just have to find the address of whatever ``normal'' symbol most
directly preceeds the symbol you care about and then figure out the distance
from that symbol to the symbol you do care about.  Then you can get the
address of the symbol that you do care about by doing something like:

	print &preceeding_symbol+0x7e

where `0x7e' is the distance between `preceeding_symbol' and the symbol that
you actually care about, e.g. `.foo'.

And before you ask, yes, it *is* a bummer that the assembler accepts names
(for symbols) that gdb cannot deal with, but you've got to remember that gdb
is first and foremost a ``source level'' debugger (for C, C++, etc.)... not
an assembly level debugger.

P.S.  Actually, symbols with periods probably shouldn't even be showing up
in your gdb-disassembled output *or* in your object file symbol tables.
If they are, then this may perhaps just be due to a small glitch in the
specific versions of the FreeBSD assembler that you are using.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?66900.943646460>