[TUHS] looking for a quote

[Clem Cole]

On Thu, Dec 7, 2017 at 4:06 PM, Theodore Ts'o <tytso at mit.edu> wrote:

> On Thu, Dec 07, 2017 at 05:45:00PM +0000, Ralph Corderoy wrote:
> > Hi Ted,
> >
> > > The reason why it's useful is that it's much more likely to find
> > > relevant lines of code by using "grep st_size *.[ch]".  If you grep
> > > for "size", there will be way too many false matches.
> >
> > True, but hasn't static analysis come on since then?  I don't use them,
> > but tools like http://ffevotte.github.io/clang-tags/ build on clang's
> > work to allow queries like finding all mentions of st_size AFAIK.
> > They'll even cope with two different struct definitions with a st_size
> > kicking about and use the one you give as a seed reference.
>
> First of all, these tools didn't exist in the days of BSD 4.x.
>
> Second of all, those tools aren't integrated into ctags and etags, so
> for the needs of working programmers, the need to run some modified
> clang and then parse clang output when trying to figure out where all
> the places that use some structure field would be unnecessarily
> complex and destructive of a working programmer's productivity.
>
> So arguably the tools *still* don't exist in a useful form for
> developers to use.
>
> > I'm surprised with things like DWARF in ELF that compilers weren't used
> > to generate a super `ctags' longer ago.  We had cscope, that was Bell
> > Labs IIRC.  And then there's been GNU GLOBAL, GNU's idutils, ...
>
> DWARF is incredibly bloated for large projects, because unless the
> header files which are #included in each .c file is exactly the same
> (the exact same header files, included in the exact same order, with
> no other local structure or type definitions in the C source file),
> there will N different copies of the structure information in the .o
> files, and this duplication will also exist in combined executable's
> DWARF information.
>
> I complained about this a decade ago, when this defect essentially
> made Systemtap completely unusable by real kernel developers.
> Compiling with DWARF exploded the compile time, and size of the build
> tree, and the size of the insatlled kernel, by a factor of at least
> ten.  We now have a way of generated reduced debuginfo files, but it
> works by eliding all of the structure definitions, and only keeping
> the file/line number information.  So that won't work for your "super
> ctags" proposal.
>
> If you want to try to fix this, feel free --- but we don't actually
> have a solution that works in the real world today.  It's something
> that only really works in the Powerpoint Slideware world inhabited by
> IBM executives....
>
>                                                 - Ted
>
​+1​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171207/056b9674/attachment.html>