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