Just wondering if anyone has written a script or something that does indenting of relay traces. I don't know how other people handle these, but I find that I invariably spend a lot of time indenting the calls in relay trace files to make them easier to follow. It would seem like something that someone would already have an automated method of handling (or maybe I'm the only one that does this).
On Sunday 02 March 2003 05:57 pm, Duane Clark wrote:
Just wondering if anyone has written a script or something that does indenting of relay traces. I don't know how other people handle these, but I find that I invariably spend a lot of time indenting the calls in relay trace files to make them easier to follow. It would seem like something that someone would already have an automated method of handling (or maybe I'm the only one that does this).
I've never seen such a thing but it would be really cool if it existed.
The hard, but really, really, really cool thing, I reckon, would be if we were able to "automagically" indent them (presumably this is what you are looking for anyhow). I imagine, if we took a "snapshot" of the stack on each debugmsg, and compared it against the stack the next time a debugmsg was issued, we could do it some, but not all of the time. API's that are just internal "workhorse" API's can just always indent their debugmsg's; I tried this for a while in the rpc code but found it was pretty difficult to maintain that way, and, when it broke, disproportionately confusing to fix.... so I reverted those in a subsequent patch. It is probably dangerous to go crawling around following stack pointers every time a debugmsg is issued, but maybe some careful exception handling code could handle the fallout.
Of course, the performance hit would be disgusting... And compiler inlining would break it... I guess it's probably more trouble than its worth... unless someone knows of a better way? Could API snooping be re-jiggered, somehow, to increment some static, thread-local integer on each call, and decerement it on each return, for example?
On March 2, 2003 07:24 pm, Gregory M. Turner wrote:
Of course, the performance hit would be disgusting... And compiler inlining would break it... I guess it's probably more trouble than its worth... unless someone knows of a better way? Could API snooping be re-jiggered, somehow, to increment some static, thread-local integer on each call, and decerement it on each return, for example?
Why can't all this be done by an external tool? There's no point in bloating Wine to do it, if piping the output through a postprocessor would do it, no?
I was under the impression this is what tools/examine-relay did?
I never understood exactly how it does the indents though, it does it in a slightly non-intuitive way
On Mon, 2003-03-03 at 06:36, Dimitrie O. Paun wrote:
On March 2, 2003 07:24 pm, Gregory M. Turner wrote:
Of course, the performance hit would be disgusting... And compiler inlining would break it... I guess it's probably more trouble than its worth... unless someone knows of a better way? Could API snooping be re-jiggered, somehow, to increment some static, thread-local integer on each call, and decerement it on each return, for example?
Why can't all this be done by an external tool? There's no point in bloating Wine to do it, if piping the output through a postprocessor would do it, no?
Mike Hearn wrote:
I was under the impression this is what tools/examine-relay did?
I never understood exactly how it does the indents though, it does it in a slightly non-intuitive way.
That is very close to what I want. I have started making mods to it, and will submit it probably as a separate tool, "indent-relay".
Mike Hearn wrote:
I was under the impression this is what tools/examine-relay did?
I never understood exactly how it does the indents though, it does it in a slightly non-intuitive way
non intuitive ? the only issue examine-relay currently have is that it doesn't split the output on the thread by thread basis... so, non intuition may mean thread switch ;-) basically, examine-relay scans every relay output... and recreates the stack on a per thread basis... if it encounters a CALL, it pushes the info as a func call... if it's a RET, it pops the function call
(well, script is a bit more complicated because of, for example, missing function RET, like you could get while in exception handling, or mixed relay and other types of traces...)
I have some patches in my tree to keep in sync with latest relay output, I may submit them one day or the other
A+
Hi, On Monday 03 March 2003 18:57, Eric Pouech wrote:
Mike Hearn wrote:
I was under the impression this is what tools/examine-relay did?
I never understood exactly how it does the indents though, it does it in a slightly non-intuitive way
non intuitive ? the only issue examine-relay currently have is that it doesn't split the output on the thread by thread basis... so, non intuition may mean thread switch ;-)
I think by non-intuitive he means that the calling function is displayed BELOW the called function. this is because of the way the script works. And I call that non-intuitive too. I think it should be the other way around.
basically, examine-relay scans every relay output... and recreates the stack on a per thread basis... if it encounters a CALL, it pushes the info as a func call... if it's a RET, it pops the function call
AND then it writes out the function so basicly if foo calls bar then the display look like this: bar foo while it should be: foo bar
(well, script is a bit more complicated because of, for example, missing function RET, like you could get while in exception handling, or mixed relay and other types of traces...)
I have some patches in my tree to keep in sync with latest relay output, I may submit them one day or the other
A+
Enrico farmboy1@subdimension.com
-
Dimitrie O. Paun -
Duane Clark -
Enrico Horn -
Eric Pouech -
Gregory M. Turner -
Mike Hearn