Dead code by symbols

Dead code by symbols

[Dr. David Alan Gilbert]

Hi David,
  A while ago we were chatting about me spotting dead structs, and
you wondered if it might be possible to spot dead functions that
were exported from an object but never used - and I've been trying
it for the last few days.

  I'm pretty early on, but it's already got some fun things:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=6a36d828bdef0e02b1e6c12e2160f5b83be6aab5
  Core code not used for ~20 years

https://lore.kernel.org/lkml/1690847.1726346402@warthog.procyon.org.uk/
  A bug! A recently added function that lost the place it was wired up
  so was currently unused.

https://lore.kernel.org/lkml/ZuXOWjvVYa64c1-5@gallifrey/
  A few small dead files.

Now, it does take some more guesswork, for example an unused function
which was added a couple of years back, might be something that's
there for consistency, might have been forgotten to be wired up,
or might just be something that's going to be used but the
authors haven't got to it yet, e.g.
   https://lore.kernel.org/lkml/ZuRGRKU9bjgC52mD@gallifrey/

My patience varies from Ooh core code, to meh old driver to very meh
for old undead staging code.

  I've got some nasty awk which kind of works some of the time;
but it does require a lot of handholding; often things like inlining
isn't spotted so gives a false positive, and I'm only looking at
the objects from a single architecture, so again have to grep
for the symbol name to make sure it's not used by a different
architecture build.

  And heck, I wish git log -G was faster.

Anyway, thanks for the suggestion!

Dave

Nasty scripts:

find . -name \*.o -exec ~/sym/dosyms {} \;

dosyms:
---------------
echo $1
DIR=$(dirname $1)
NEWN=$DIR/$(basename -s .o $1).x

readelf -W -s -r $1 | awk -f ~/sym/relocs.awk |sort|uniq > $NEWN
---------------

awk -f ~/sym/collate.awk $(find . -name \*.x)

collate.awk:
---------------

{ if (($1=="u") || ($1=="U")) {
    use[$2]=use[$2] "," FILENAME
    usecount[$2]++
  } else {
    def[$2]=def[$2] ",:" $1 ":" FILENAME
    defcount[$2]++
  }
}
END {
  for (s in def) {
    if (usecount[s] == 0) {
      printf("%s:%d: %s from %s\n", s, usecount[s], use[s], def[s]) 
    }
  }
}

---------------


-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: Dead code by symbols

[David Hildenbrand]

On 16.09.24 14:33, Dr. David Alan Gilbert wrote:
> Hi David,
>    A while ago we were chatting about me spotting dead structs, and
> you wondered if it might be possible to spot dead functions that
> were exported from an object but never used - and I've been trying
> it for the last few days.
> 
>    I'm pretty early on, but it's already got some fun things:

Cool, stuff! :)

> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=6a36d828bdef0e02b1e6c12e2160f5b83be6aab5
>    Core code not used for ~20 years
> 
> https://lore.kernel.org/lkml/1690847.1726346402@warthog.procyon.org.uk/
>    A bug! A recently added function that lost the place it was wired up
>    so was currently unused.

That is really nice!

> 
> https://lore.kernel.org/lkml/ZuXOWjvVYa64c1-5@gallifrey/
>    A few small dead files.
> 
> Now, it does take some more guesswork, for example an unused function
> which was added a couple of years back, might be something that's
> there for consistency, 

I know people will find reasons to do something like that, but we really 
*shouldn't* be maintaining / dragging along dead code that nobody might 
ever use.

> might have been forgotten to be wired up,

Forgotten as in "BUG" or as in "ran out of steam" ?

> or might just be something that's going to be used but the
> authors haven't got to it yet, e.g.
>     https://lore.kernel.org/lkml/ZuRGRKU9bjgC52mD@gallifrey/

Yes, that' a valid case.

> 
> My patience varies from Ooh core code, to meh old driver to very meh
> for old undead staging code.

:)

> 
>    I've got some nasty awk which kind of works some of the time;
> but it does require a lot of handholding; often things like inlining
> isn't spotted so gives a false positive, and I'm only looking at
> the objects from a single architecture, so again have to grep
> for the symbol name to make sure it's not used by a different
> architecture build.
> 
>    And heck, I wish git log -G was faster.

:)

> 
> Anyway, thanks for the suggestion!

Glad you're able to spot some nice (+fun, otherwise you wouldn't be 
doing it ;) ) things!

-- 
Cheers,

David / dhildenb

Re: Dead code by symbols

[Dr. David Alan Gilbert]

* David Hildenbrand (david@redhat.com) wrote:
> On 16.09.24 14:33, Dr. David Alan Gilbert wrote:
> > Hi David,
> >    A while ago we were chatting about me spotting dead structs, and
> > you wondered if it might be possible to spot dead functions that
> > were exported from an object but never used - and I've been trying
> > it for the last few days.
> > 
> >    I'm pretty early on, but it's already got some fun things:
> 
> Cool, stuff! :)
> 
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=6a36d828bdef0e02b1e6c12e2160f5b83be6aab5
> >    Core code not used for ~20 years
> > 
> > https://lore.kernel.org/lkml/1690847.1726346402@warthog.procyon.org.uk/
> >    A bug! A recently added function that lost the place it was wired up
> >    so was currently unused.
> 
> That is really nice!
> 
> > 
> > https://lore.kernel.org/lkml/ZuXOWjvVYa64c1-5@gallifrey/
> >    A few small dead files.
> > 
> > Now, it does take some more guesswork, for example an unused function
> > which was added a couple of years back, might be something that's
> > there for consistency,
> 
> I know people will find reasons to do something like that, but we really
> *shouldn't* be maintaining / dragging along dead code that nobody might ever
> use.

One example is lib/base64.c base64_encode - that's not used, but the base64_decode
in the same file is used by nvme; I've not convinced myself if it makes sense
to take the encode out or not.
(We do have ceph_base64_encode with slightly different base64 behaviour,
and then there's chap_base64_decode and ceph_base64_decode which are all different;
it's pretty hideous)

> > might have been forgotten to be wired up,
> 
> Forgotten as in "BUG" or as in "ran out of steam" ?

BUG like the afs one above where the function exists but the line
to use it got lost.
But there are 'ran out of steam' ones as well - eg bc9ab6d31c4f
added a function for 'runtime reconfiguration' to an audio codec
with a note that some systems require it; as far as I can tell
it was never used.  Since that was over 10 years ago it's probably
time for it to go, but if it was only a year or so old then maybe
it would still be something that might be getting added.

> > or might just be something that's going to be used but the
> > authors haven't got to it yet, e.g.
> >     https://lore.kernel.org/lkml/ZuRGRKU9bjgC52mD@gallifrey/
> 
> Yes, that' a valid case.
> 
> > 
> > My patience varies from Ooh core code, to meh old driver to very meh
> > for old undead staging code.
> 
> :)
> 
> > 
> >    I've got some nasty awk which kind of works some of the time;
> > but it does require a lot of handholding; often things like inlining
> > isn't spotted so gives a false positive, and I'm only looking at
> > the objects from a single architecture, so again have to grep
> > for the symbol name to make sure it's not used by a different
> > architecture build.
> > 
> >    And heck, I wish git log -G was faster.
> 
> :)
> 
> > 
> > Anyway, thanks for the suggestion!
> 
> Glad you're able to spot some nice (+fun, otherwise you wouldn't be doing it
> ;) ) things!

Dave

> -- 
> Cheers,
> 
> David / dhildenb
> 
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: Dead code by symbols

[Christoph Hellwig]

On Tue, Sep 17, 2024 at 01:39:35PM +0200, David Hildenbrand wrote:
> > Now, it does take some more guesswork, for example an unused function
> > which was added a couple of years back, might be something that's
> > there for consistency,
> 
> I know people will find reasons to do something like that, but we really
> *shouldn't* be maintaining / dragging along dead code that nobody might ever
> use.

There never is any reason to keep dead code around.

Re: Dead code by symbols

[Dr. David Alan Gilbert]

* Christoph Hellwig (hch@infradead.org) wrote:
> On Tue, Sep 17, 2024 at 01:39:35PM +0200, David Hildenbrand wrote:
> > > Now, it does take some more guesswork, for example an unused function
> > > which was added a couple of years back, might be something that's
> > > there for consistency,
> > 
> > I know people will find reasons to do something like that, but we really
> > *shouldn't* be maintaining / dragging along dead code that nobody might ever
> > use.
> 
> There never is any reason to keep dead code around.

Yeh I mostly agree; and indeed I'll be sending many many patches to remove
the bucket loads of dead code I find; but as I say, there's a really
big variation from the dead-for-20 years, to relatively new, to 
functions that seem to make sense next to the file they're part of.
So I'll get to those later, I'll get rid of the very dead ones first.

Dave

> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: Dead code by symbols

[David Hildenbrand]

On 18.09.24 12:55, Dr. David Alan Gilbert wrote:
> * Christoph Hellwig (hch@infradead.org) wrote:
>> On Tue, Sep 17, 2024 at 01:39:35PM +0200, David Hildenbrand wrote:
>>>> Now, it does take some more guesswork, for example an unused function
>>>> which was added a couple of years back, might be something that's
>>>> there for consistency,
>>>
>>> I know people will find reasons to do something like that, but we really
>>> *shouldn't* be maintaining / dragging along dead code that nobody might ever
>>> use.
>>
>> There never is any reason to keep dead code around.
> 
> Yeh I mostly agree; and indeed I'll be sending many many patches to remove
> the bucket loads of dead code I find; but as I say, there's a really
> big variation from the dead-for-20 years, to relatively new, to
> functions that seem to make sense next to the file they're part of.
> So I'll get to those later, I'll get rid of the very dead ones first.

Makes sense to me. Thanks for doing that work, Dave!

-- 
Cheers,

David / dhildenb