All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: David Rientjes <rientjes@google.com>
Cc: <linux-kernel@vger.kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, <x86@kernel.org>
Subject: Re: [PATCH] x86: fix two sparse warnings in early boot string handling
Date: Wed, 12 Feb 2014 10:49:27 -0500	[thread overview]
Message-ID: <52FB9807.40706@windriver.com> (raw)
In-Reply-To: <52FB8BEB.5020506@windriver.com>

On 14-02-12 09:57 AM, Paul Gortmaker wrote:
> On 14-02-11 09:23 PM, David Rientjes wrote:
>> On Tue, 11 Feb 2014, Paul Gortmaker wrote:
>>
>>>>> Fixes:
>>>>>
>>>>> arch/x86/boot/compressed/../string.c:60:14: warning: symbol 'atou' was not declared. Should it be static?
>>>>> arch/x86/boot/string.c:133:6: warning: symbol 'strstr' was not declared. Should it be static?
>>>>>
>>>>> The atou one could be considered a false positive; it seems somehow
>>>>> caused by including ./string.c from within /compressed/string.c file.
>>>>> However git grep shows only the atou prototype and declaration, so
>>>>> it is completely unused and we can hence delete it.
>>>>>
>>>>
>>>> Declaring a prototype in a header file would be pointless if there is no 
>>>> current breakage; I don't see why you can't remove strstr() in 
>>>> arch/x86/boot/string.c entirely.  What breaks?
>>>
>>> Explicit breakage vs. sparse warnings are two different things.  It may
>>> be that we can delete strstr() just like I did for atou() -- but in the
>>> interest of doing the minimal change, I did just what was needed for
>>> fixing the sparse warnings for strstr.  I can test if it can be removed,
>>> but it has the smell of generic-libc usage all over it...
>>>
>>
>> When the minimal change is to add an unnecessary prototype for a function 
>> that is not referenced, it doesn't seem acceptable.
> 
> OK, fair enough -- it seems surprisingly unused, as well as strcmp, despite
> my gut feeling that they'd be used in multiple places.  I'll send a v2
> that deletes all three once it passes allyesconfig on linux-next for x86
> 32/64/uml.

Actually no v2 pending.  The original v1 patch was/is correct as-is.

While x86-64 defconfig passed, it turns out that both strcmp and strstr
have to stay, else we will get this on i386 allyesconfig builds:

arch/x86/boot/compressed/eboot.o: In function `handle_cmdline_files.isra.5.constprop.6':
eboot.c:(.text+0x4cf): undefined reference to `strstr'
eboot.c:(.text+0x601): undefined reference to `strstr'
make[2]: *** [arch/x86/boot/compressed/vmlinux] Error 1

arch/x86/boot/edd.o: In function `query_edd':
arch/x86/boot/edd.c:136: undefined reference to `strcmp'
arch/x86/boot/edd.c:136: undefined reference to `strcmp'
arch/x86/boot/edd.c:140: undefined reference to `strcmp'
arch/x86/boot/edd.c:142: undefined reference to `strcmp'
make[1]: *** [arch/x86/boot/setup.elf] Error 1

So my gut feeling was right after all.  ;)

Thanks,
Paul.
--

  reply	other threads:[~2014-02-12 15:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-11 18:33 [PATCH] x86: fix two sparse warnings in early boot string handling Paul Gortmaker
2014-02-11 22:26 ` David Rientjes
2014-02-12  2:00   ` Paul Gortmaker
2014-02-12  2:23     ` David Rientjes
2014-02-12 14:57       ` Paul Gortmaker
2014-02-12 15:49         ` Paul Gortmaker [this message]
2014-02-12 22:00           ` David Rientjes
2014-02-12 22:29             ` Paul Gortmaker
2014-02-12 23:14               ` David Rientjes
2014-02-12 23:31                 ` H. Peter Anvin
2014-02-13 10:31                   ` Matt Fleming
2014-02-13 14:01                     ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52FB9807.40706@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.