This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] MI: new timing command


> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Mon, 1 Jan 2007 17:22:18 +1300
> Cc: Vladimir Prus <ghost@cs.msu.su>, mark.kettenis@xs4all.nl,
> 	gdb-patches@sources.redhat.com
> 
>  > > And lose user/system/elapse time distinction?
>  > 
>  > You don't have to lose it.  How about if we use getrusage directly if
>  > it's available, else the libiberty replacement?  That way, everybody
>  > will be as happy as they can expect, I think.
> 
> If we adopt this approach can you please explain to me how to interpret the
> output of get_run_time when getrusage is not availble so I can add it to the
> doc.

I think it should be interpreted the same as the results from
getrusage.  What made you think it needs special interpretation?

If the problem is that get_run_time returns a single number instead of
3 numbers, I think we should simply display the other 2 as zeroes, or
maybe use some MI convention for results that aren't available, if
there is such a convention.

>  > You are not the only user of GDB.
> 
> -enable-timing would only be used by developers of frontends to GDB using MI.
> Currently Vladimir and myself do almost appear to be the only users.

Let's not enter the argument of how many people we can count that will
use this command.  Features are added to GDB for the benefit of
everybody, not just the couple of people whom we know to need them.

>  >                                    There's no reason to gratuitously
>  > confine features to the only platform that you are interested in.
> 
> It not gratuitous because generalising it involves extra work in areas
> we don't understand.  

What areas are those?  I don't see any particular extra work required
in the simple solution I proposed.  Maybe I'm missing something.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]