Re: kdump -E for time elapsed since the beginning of trace

[Taylor R Campbell <campbell+netbsd-tech-userlevel%mumble.net@localhost>]

> Date: Thu, 7 Sep 2017 05:34:00 +0300
> From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
> 
> PS: You may notice on some platforms that the second entry (execve)
> has 1) negative time, 2) incorrect negative time.
> 
> $ ktrace date && kdump -TE | sed 2q
> Thu Sep  7 05:30:09 MSK 2017
>   5995      1 ktrace   1504751409.989461831 0.000000000 EMUL  "netbsd"
>   5995      1 ktrace   1504751409.989459379 -1.999997548 CALL  execve(...)
> 
> Where 1504751409.989459379 - 1504751409.989461831 = -0.000002452
> not -1.999997548
> 
> These are pre-existing bugs.

For the record, we ascertained on IRC that the problem is in kdump's
interpretation of negative timespec objects for printing, not, say, in
the timespec arithmetic.

Specifically, the number of seconds represented by a timespec object
ts is always

   ts.tv_sec + 1e-9*ts.tv_nsec,

where ts.tv_sec may be negative but ts.tv_nsec is always in [0, 1e9).
So, for example, -1/4 second is represented by the struct timespec
object {.tv_sec = -1, .tv_nsec = 750000000}.  But kdump *prints* it as
if it were

   sign(ts.tv_sec)*(|ts.tv_sec| + 1e-9*ts.tv_nsec)

where sign(x) is -1 if x < 0 and 1 if x >= 0, and so for the struct
timespec object representing -1/4, kdump prints -1.750000000 where
instead it should really print -0.250000000.

Easy fix, but I will let uwe@ incorporate it into the patch or wait
until the patch is committed before making potentially conflicting
changes.