This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb "step" behavior in multi-threaded programs


Kevin Hilman wrote:
I'm working on the eCos gdb stub for new architecture, and I'm a bit
confused about the correct gdb behavior for breaking/stepping for
multi-threaded programs.  For example, if you have a function being
called by multiple threads and you set a breakpoint at that function.

I presume that for breakpoints, whenever ANY thread calls that
function, the breakpoint should be hit, right?
Correct, although GDB has the concept of per-thread breakpoints. See the GDB documentation for details...

Although in practice per-thread breakpoints are implemented by letting every thread hit the breakpoint anyway and GDB just resuming the target without user input.

What about stepping in that function (via the "step" command)? Should
gdb stop whenever ANY thread hits the next source line? or just the
thread that hit the breakpoint?  And what about "stepi"?
Since GDB has per-thread breakpoints it certainly can do it for only one thread, and I believe it does (bugs aside).

The GDB info files have stuff about scheduler locking too to allow threads to be stepped without the risk of unnecessary task switches. This is supported in the eCos GDB stub.

Jifl
--
eCosCentric http://www.eCosCentric.com/ <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]