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

[Paulo Marques]

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/