This is the mail archive of the archer@sourceware.org mailing list for the Archer 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: Syscall tracing


On Tue, Aug 5, 2008 at 1:30 PM, Doug Evans <dje@google.com> wrote:
> On Tue, Aug 5, 2008 at 11:43 AM, Thiago Jung Bauermann
> <bauerman@br.ibm.com> wrote:
>> Ok, let me see if I understood this correctly...
>>
>> On Thu, 2008-07-31 at 19:28 -0700, Roland McGrath wrote:
>>> To pretty-print an object of a type defined by some DSO, for the first
>>> piece we use the DWARF type descriptions that encode the ABI's layout,
>>> names, and types.  I'd always figured this is the right thing to do for the
>>> syscall ABI too.  This enables not just pretty-printing, but using the
>>> details in expression evaluation, GUI data inspectors, etc.
>>
>> So with your approach there's no need to augment DWARF with special
>> attributes like Daniel suggested, right? The semantic intelligence would
>> be in the pretty-printer...
>>
>>> So that unifies the second piece with the general pretty-printing issue.
>>> The kernel delivering its syscall ABI and how to make that pretty is just
>>> like some user libraries delivering its DSO ABIs and how to make that data
>>> pretty.
>>
>> This means that we would try to convince the kernel folks to provide
>> Python pretty-printers to GDB, right?
>
> I'm not sure the following is equivalent, but I would word it thusly,
>
> 1) someone (kernel folks, whatever), supply information to libstrace2
> (or whatever)
>    [I only picked that name out of laziness, the point is to
> (hopefully) keep the focus on providing what (apparently) strace2 was
> going to be
> 2) libstrace2 folks provide library to gdb (and everyone else that
> wants to use it)
> 3) gdb uses libstrace2

Hit send too soon.  Blech.
To complete the thought, I'd expect gdb folks to be writing the python
(or c/c++) since it's code specific to gdb, but I also would expect
that not much python needs to be written as most of the work would
come from libstrace2 in an application independent form.

And, to hopefully avoid any confusion, I'm using "libstrace2" as a
placeholder for whatever the implementation turns out to be.  It could
be just a library, it could be a database from which code is
generated, or whatever.


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