From: Daniel Jacobowitz <drow@mvista.com>
To: "Cheng, Cheuk" <cheng@powertv.com>
Cc: gdb@sources.redhat.com
Subject: Re: Breakpoint and static functions
Date: Mon, 16 Dec 2002 18:06:00 -0000 [thread overview]
Message-ID: <20021217020728.GA10076@nevyn.them.org> (raw)
In-Reply-To: <762C0A863A7674478671627FEAF584812D798B@hqmail01.powertv.com>
On Mon, Dec 16, 2002 at 05:24:41PM -0800, Cheng, Cheuk wrote:
> Hi, I am new to GDB and am having problem with the following. I am
> using a propietary OS running from ROM on an usparc based embedded
> system. This OS has a GDB nub (written in C and inline assembly) in it.
> Here is what I do.
>
> - Boot up usparc hardware containing debug build of OS in ROM.
>
> - set up GDB remote debug link from my PC to the hardware.
>
> - Enter "file osdebug.cof" at GDB prompt.
>
> - Enter "add-symbol-file application.cof <load_address>" at GDB prompt.
>
> - Enter "target rem com1" at GDB prompt.
>
> - Enter command to load application into RAM inside a PC terminal
> program. Wait for it to finish loading.
>
> - Enter command inside PC terminal program to tell the OS to break into
> GDB.
>
> - Enter "b <some_static_function>" at GDB prompt. Continue application
> execution.
>
> - GDB breaks at <some_static_function>. Enter "continue" to go on.
>
> - GDB returns "Program received signal SIGTRAP, Trace/breakpoint trap."
> Now even after I use the "delete" command to remove the breakpoint, if I
> "continue" GDB will still break at the same spot. Using the "clear"
> command does not help too.
>
> - Now if I change the source code of the application to make the
> function non-static (by removing "static" in the function prototype and
> rebuild the application binary), then the above message will still
> appear (and the line number indicated by this message is still a few
> lines before where I originally set the breakpoint, e.g. b <> was at
> 9874 while the message indicated break at 9871"). However after I
> "delete" the original breakpoint, the message appears once and then I
> can "continue" one more time and no more stopping from now on.
>
> Am I doing something wrong in GDB? Or can that be our GDB nub inside
> the OS is bad (although I can always use the "list" command to view any
> source module without any problem)? Or is the use of static function
> with GDB problematic? Is it sufficient to have a GDB nub linked into
> the OS which is running from ROM or the application has to have its own
> GDB nub?
It sounds like it's having a problem with the technique that you're
using for single stepping, at a guess. Could you send the output of
this session after saying 'set debug target 1' and 'set debug remote
1' (before you say "target remote com1").
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2002-12-17 2:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-16 17:22 Cheng, Cheuk
2002-12-16 18:06 ` Daniel Jacobowitz [this message]
2002-12-17 10:13 Cheng, Cheuk
2002-12-17 10:23 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021217020728.GA10076@nevyn.them.org \
--to=drow@mvista.com \
--cc=cheng@powertv.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox