From owner-freebsd-hackers Fri Nov 26 12:10:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 8DC2415112; Fri, 26 Nov 1999 12:10:49 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id MAA66902; Fri, 26 Nov 1999 12:01:00 -0800 (PST) To: Marc Tardif Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: disassembling syscalls In-reply-to: Your message of Fri, 26 Nov 1999 14:31:05 -0500. Date: Fri, 26 Nov 1999 12:01:00 -0800 Message-ID: <66900.943646460@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , 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