 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi guys.
I just read the entire manpage for ptrace(2).
WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH!! O_O
OK, first of all, that's the longest manpage I've ever seen! (A typical
manpage seems to be about three paragraphs.) Second... OK, I was
wondering what strace(1) actually does, and how hard it would be to
reimplement it myself. As it turns out... yeah, pretty damned hard,
actually. O_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 27 Nov 2014 21:42:11 +0000, Orchid Win7 v1 wrote:
> Subject: Man oh man
I see what you did there. ;)
It's a good thing you weren't reading the man page for mplayer, postconf,
or smb.conf - those are all over 10,000 lines long on my system.
Comparatively speaking, ptrace(2) is relatively short (only about 1,000
lines). ;)
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Subject: Man oh man
>
> I see what you did there. ;)
:-D
> It's a good thing you weren't reading the man page for mplayer, postconf,
> or smb.conf - those are all over 10,000 lines long on my system.
>
> Comparatively speaking, ptrace(2) is relatively short (only about 1,000
> lines). ;)
Sure. But look at the number of ifs, buts, elses and gotchas... That's a
LOT of information to absorb.
On the one hand, it appears that essentially what strace does is fairly
simple; execute the right ptrace() call, and the tracee will go to sleep
every time it gets a signal or does a system call. You call ptrace()
again to query what happened, and then resume the tracee.
On the other hand... all those ifs and buts... CLEARLY this stuff is
really, really fiddly to get right! (And don't even get me started on
decoding the system calls.)
Having read the manpage, it appears that parsing the text output of
strace is probably going to be easier than reimplementing it to output
XML or something.
(I did take a look at the source code for strace... Every single source
file contains hundreds of printf() calls. I was hoping for more
abstraction than that. Clearly there's no way of altering what its
output looks like without months of work.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 27 Nov 2014 22:31:05 +0000, Orchid Win7 v1 wrote:
> Clearly there's no way of altering what its output looks like without
> months of work.)
Perhaps easier to pipe the output through an awk script (or similar) to
get what you're looking for.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/11/14 22:08, Jim Henderson wrote:
> On Thu, 27 Nov 2014 21:42:11 +0000, Orchid Win7 v1 wrote:
>
>> Subject: Man oh man
>
> I see what you did there. ;)
>
> It's a good thing you weren't reading the man page for mplayer, postconf,
> or smb.conf - those are all over 10,000 lines long on my system.
>
> Comparatively speaking, ptrace(2) is relatively short (only about 1,000
> lines). ;)
>
> Jim
>
>
>
Try: man gcc
16,153 lines on the machine I'm working on.
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28/11/14 11:56, Doctor John wrote:
> Try: man gcc
>
> 16,153 lines on the machine I'm working on.
>
> John
>
Whilst I'm at it:
john@aphrodite:~> man mplayer | wc -l
8754
john@aphrodite:~> man smb.conf | wc -l
7948
john@aphrodite:~> man postconf | wc -l
307
john@aphrodite:~> man gcc | wc -l
16153
john@aphrodite:~> man ptrace | wc -l
962
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Doctor John <j.g### [at] gmail com> wrote:
> Whilst I'm at it:
> john@aphrodite:~> man mplayer | wc -l
> 8754
> john@aphrodite:~> man smb.conf | wc -l
> 7948
> john@aphrodite:~> man postconf | wc -l
> 307
> john@aphrodite:~> man gcc | wc -l
> 16153
> john@aphrodite:~> man ptrace | wc -l
> 962
bash has all of its info on one single man page, 5450 lines long in
my system.
zsh has enormously more info, which is why it's subdivided into a
dozen man pages by category. There is, however, a 'zshall' man page
where everything is concatenated, and it's 27499 lines long on my
system.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28/11/14 14:53, Warp wrote:
>
> bash has all of its info on one single man page, 5450 lines long in
> my system.
>
> zsh has enormously more info, which is why it's subdivided into a
> dozen man pages by category. There is, however, a 'zshall' man page
> where everything is concatenated, and it's 27499 lines long on my
> system.
>
Just checked that on mine
john@aphrodite:~> man zshall | wc -l
24375
... same order of immensity ;-)
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/11/2014 11:52 PM, Jim Henderson wrote:
> On Thu, 27 Nov 2014 22:31:05 +0000, Orchid Win7 v1 wrote:
>
>> Clearly there's no way of altering what its output looks like without
>> months of work.)
>
> Perhaps easier to pipe the output through an awk script (or similar) to
> get what you're looking for.
I spent 2 days writing an elaborate parser for it. But clearly, not
elaborate enough! Because I'm *still* getting parse failures... Hey,
it's not like it has a documented grammar or anything. Every time you
think you've covered everything, another special case pops up. :-S
I have, however, managed to boil 27 MB of strace logs down into a 2MB
HTML file that's colour-coded in such a way that you can just about see
what's going on. (It seems several processes received SIGINT, but for no
defined reason THEY CONTINUE RUNNING! >_< I have no idea why.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 29 Nov 2014 21:57:25 +0000, Orchid Win7 v1 wrote:
> (It seems several processes received SIGINT, but for no defined reason
> THEY CONTINUE RUNNING! >_< I have no idea why.)
Because signals can be captured, ignored, or their behaviours can be
changed. SIGINT is just a signal to a program, and writing an
interceptor isn't that difficult. :)
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
