lkml.org 
[lkml]   [2006]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [SOLVED] Trap flag handling change in 2.6.10-bk5 broke Kylix debugger
Linus Torvalds wrote:
> On Thu, 16 Feb 2006, Paulo Marques wrote:
> [...]
>>I did a workaround in the interposer (remembering that a single step was
>>requested so that it sets the trap flag on the next call to ptrace) and the
>>debugger actually works, but I would prefer to do it better.
>
> Ok. It does seem like the debugger is using the TF bit in the debuggee to
> "remember" whether it was single-stepping or not.
>
> Which is pretty insane.

It sure is :P

>>BTW, is there a good way to do the "test_tsk_thread_flag(child,
>>TIF_SINGLESTEP)" from user space?
>
> Not really. Except you should just remember that you asked for
> single-stepping. That, together with the status return on the wait (which
> tells you why the process stopped - the single-step could have been
> aborted because of a real fault), should be plenty good enough, and sounds
> like the natural way to do this.

I think I can do a better interposer, then. I can interpose both the
ptrace and the wait functions so that I can keep an internal "is being
single stepped" state for each process being ptrace'd.

> Relying on the TF bit, which is under the control of the debugged
> application itself, is kind of hokey.

If I understand this correctly, if the kernel had some other way of
producing a single step (a new flag on newer processors, a timer
interrupt going on after one cycle, whatever) it might not even set the
trap flag at all, and still execute perfectly well the ptrace syscalls,
with all the expected signals being generated, etc.

So this is very much implementation dependent, and the application
should not rely on internal kernel mechanisms like that...

> So your patch isn't too intrusive, which is nice. The thing that _isn't_
> nice about it is that it means that the debugger cannot actually set the
> TF bit "for real" on the process it is debugging, and it cannot really ask
> for what the state of the TF bit is (because it will be overshadowed by
> the debugger single-stepping).

The patch wasn't meant to be used like that. It was just to show what
was needed to make the debugger happy.

At the very least, the patch needs a lot more comments and a quarantine
on -mm before it can be used on mainline.

> So I like your patch because it re-instates old (admittedly broken)
> behaviour without breaking the _internal_ kernel logic (just the "external
> interface"). And while the old behaviour _was_ broken, being backwards
> compatible is damn important.
>
> That said, I'd be a lot happier if we could just fix Kylix instead ;(

The interposer is the closest thing we have to "fixing kylix". I think
most kylix users will be perfectly happy with the interposer and we
really don't need to change the kernel. They are already used to work
around problems that arise from the total staleness of the project.

I'll try to send a few posts to Kylix forums with the interposer thing
and see how well it is accepted.

From what I've heard, Borland is selling its languages, including
Delphi and Kylix, so maybe the company that buys it will be more willing
to properly maintain kylix in the future :)

--
Paulo Marques - www.grupopie.com

Pointy-Haired Boss: I don't see anything that could stand in our way.
Dilbert: Sanity? Reality? The laws of physics?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-17 15:48    [W:0.188 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site