Re: [SOLVED] Trap flag handling change in 2.6.10-bk5 broke Kylixdebugger

From: Paulo Marques
Date: Fri Feb 17 2006 - 09:43:57 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/