Re: Multi-Task Procs in the SourceWindow

[Mike Cvet <mcvet@redhat.com>]

On Tue, 2006-10-10 at 09:46 +0800, Yao Qi wrote:
> On Wed, Oct 04, 2006 at 12:18:00PM -0400, Mike Cvet wrote:
> > I've just committed a large patch which allows the SourceWindow to
> > handle processes with multiple threads. That is, it properly blocks and
> > unblocks them, and if the source code is available, should display the
> > source from each thread and highlight the appropriate lines properly.
> > 
> > Thanks to Tom's idea, it uses a TreeView widget to list each thread and
> > their respective frames on the call stack.
> > 
> > I'm pretty sure that bugs exist! If you have some free time and want to
> > check it out, I've attached an example test program. Please assign any
> > breakage to me.
> Hi, Mike,
> I run it with the example in the attachment, and the SourceWindow
> works fine to me(on x86 rawhide).  Thanks!
> 
> Here are some points that we could improve,
> 1) If we click one frame in StackWindow, appropriate lines are
> highlighted, but the SourceWindow do *not* adjust the content in it to
> display the highlighted lines, and always display source code from
> line #1.  Could we make SourceWindow to refresh, and display the
> highlighted lines in the middle of SourceWindows, when we click on frame?

I've been meaning to get around to this one.

> 
> 2) When I click one frame, there are multiple lines are highlighted.
> For example, If I click "baz" in StackWindow, line #42, #50, and #57
> are highlighted at the same time.  Is it expected?  IMO, we could only
> highlight the *current* frame, instead of call tree, which has been
> displayed in StackWindow.

Yeah, I was wondering about this one myself. I *could* see usefulness
for this, but more often than not its probably confusing. I'll get rid
of it for now

> 
> 3) Multiple source file is not support.
> If I put do_it() in tester1.c, and compile the test like this,
> $ gcc -g tester1.c tester2.c -o test -lpthread
> 
> and then fire frysk, we could find do_it() in StackWindow, and the
> line number is #11(the correct line number), but line #11 in tester2.c
> is highlighted, instead of line #11 in teser1.c.
>