This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Breakpoint and static functions
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