1 Aug 2008 02:28
Re: Tasks
On Thu, Jul 31, 2008 at 12:57 PM, Thiago Jung Bauermann <bauerman@...> wrote: > On Tue, 2008-07-29 at 13:46 -0600, Tom Tromey wrote: >> >>>>> "Mark" == Mark Wielaard <mark@...> writes: >> >> Mark> Maybe a nice "little" task to investigate is the catch syscall >> Mark> support. That might give someone a "simple" entry into the gdb >> Mark> catch mechanism. (little and simple in quotes, since I didn't >> Mark> actually investigate myself much) >> >> I think this is a very interesting idea. >> >> Offhand I would say, those of us at Red Hat already have a full list >> with stuff just directly related to C++. Maybe somebody else could >> implement this> > I'm considering this. For a first step, we could catch the syscall but > not interpret the arguments. > > There's the question of how GDB would know about the syscall arguments. > Kernel debuginfo? That's the cleanest solution I think. But I don't know > if such debuginfo exists today. I can imagine there being multiple applications that would like this info. Can we start our own libstrace (or some such) and have gdb use that?
In my opinion, the only important thing here is the data. Strace has
a copy, but not in an extractable format; much of it is custom C.
What it needs is a more data-driven display format. Then consumers
can do with it what they will.
Perhaps it could be done as C or at least C-like? If GCC passed
special attributes into debug info, that'd be one way to produce
useful input to GDB describing the types. Another way would be a
scripted parser for the necessary (very small) subset of C.
__bitwise_combinable enum open_flags_t {
O_APPEND = 1,
O_ASYNC = 2
};
int __fd_or_error open (const char *pathname __filename,
open_flags_t flags, mode_t mode);
RSS Feed