Hi Arnd,
I recently tried to disable the BUG macros on x86-32. I disabled the
config item in 'General Setup -> Configure standard kernel features
(expert users) -> BUG() support'.
However, BUG/BUG_ON is still defined. In the !CONFIG_BUG branch in
include/asm-generic/bug.h (line 181) the code checks for the existence
of architecture-specific variants of those macros.
Since x86 defines its own version of BUG(), line 182 is *not* used.
In the following, the x86 variant of BUG() is then used to define the
BUG_ON() macro.
I propose a patch that really disables both macros if the developer
wants it.
It undefines the respective x86 variants, and defines both macros as
'empty' macros.
Regards,
Alex
--
Technische Universität Dortmund
Alexander Lochmann PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16 phone: +49.231.7556141
D-44227 Dortmund fax: +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al
On Tue, Sep 25, 2018 at 1:35 PM Alexander Lochmann
<[email protected]> wrote:
>
> Hi Arnd,
>
> I recently tried to disable the BUG macros on x86-32. I disabled the
> config item in 'General Setup -> Configure standard kernel features
> (expert users) -> BUG() support'.
> However, BUG/BUG_ON is still defined. In the !CONFIG_BUG branch in
> include/asm-generic/bug.h (line 181) the code checks for the existence
> of architecture-specific variants of those macros.
> Since x86 defines its own version of BUG(), line 182 is *not* used.
> In the following, the x86 variant of BUG() is then used to define the
> BUG_ON() macro.
>
> I propose a patch that really disables both macros if the developer
> wants it.
> It undefines the respective x86 variants, and defines both macros as
> 'empty' macros.
Maybe we should update the documentation instead. Note that the
generic version is using 'while (1)' rather than 'while (0)', so this is
not an empty macro but rather one that does more than the
arch-specific one-instruction version does.
We don't really want an empty macro any more, this was used in
the past, but causes compile-time warnings and undefined behavior
for no good reason.
Arnd
Am 25.09.2018 um 14:06 schrieb Arnd Bergmann:
> On Tue, Sep 25, 2018 at 1:35 PM Alexander Lochmann
> <[email protected]> wrote:
>>
>> Hi Arnd,
>>
>> I recently tried to disable the BUG macros on x86-32. I disabled the
>> config item in 'General Setup -> Configure standard kernel features
>> (expert users) -> BUG() support'.
>> However, BUG/BUG_ON is still defined. In the !CONFIG_BUG branch in
>> include/asm-generic/bug.h (line 181) the code checks for the existence
>> of architecture-specific variants of those macros.
>> Since x86 defines its own version of BUG(), line 182 is *not* used.
>> In the following, the x86 variant of BUG() is then used to define the
>> BUG_ON() macro.
>>
>> I propose a patch that really disables both macros if the developer
>> wants it.
>> It undefines the respective x86 variants, and defines both macros as
>> 'empty' macros.
>
> Maybe we should update the documentation instead. Note that the
> generic version is using 'while (1)' rather than 'while (0)', so this is
> not an empty macro but rather one that does more than the
> arch-specific one-instruction version does.
>
> We don't really want an empty macro any more, this was used in
> the past, but causes compile-time warnings and undefined behavior
> for no good reason
I see. So the documentation of the CONFIG_BUG option is wrong?
It currently states that 'Disabling this option eliminates support for
BUG and WARN'.
Is the current implemention (an endless loop) desired behavior?
- Alex
>
> Arnd
>
--
Technische Universität Dortmund
Alexander Lochmann PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16 phone: +49.231.7556141
D-44227 Dortmund fax: +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al
On Tue, Sep 25, 2018 at 2:13 PM Alexander Lochmann
<[email protected]> wrote:
>
>
>
> Am 25.09.2018 um 14:06 schrieb Arnd Bergmann:
> > On Tue, Sep 25, 2018 at 1:35 PM Alexander Lochmann
> > <[email protected]> wrote:
> >>
> >> Hi Arnd,
> >>
> >> I recently tried to disable the BUG macros on x86-32. I disabled the
> >> config item in 'General Setup -> Configure standard kernel features
> >> (expert users) -> BUG() support'.
> >> However, BUG/BUG_ON is still defined. In the !CONFIG_BUG branch in
> >> include/asm-generic/bug.h (line 181) the code checks for the existence
> >> of architecture-specific variants of those macros.
> >> Since x86 defines its own version of BUG(), line 182 is *not* used.
> >> In the following, the x86 variant of BUG() is then used to define the
> >> BUG_ON() macro.
> >>
> >> I propose a patch that really disables both macros if the developer
> >> wants it.
> >> It undefines the respective x86 variants, and defines both macros as
> >> 'empty' macros.
> >
> > Maybe we should update the documentation instead. Note that the
> > generic version is using 'while (1)' rather than 'while (0)', so this is
> > not an empty macro but rather one that does more than the
> > arch-specific one-instruction version does.
> >
> > We don't really want an empty macro any more, this was used in
> > the past, but causes compile-time warnings and undefined behavior
> > for no good reason
> I see. So the documentation of the CONFIG_BUG option is wrong?
> It currently states that 'Disabling this option eliminates support for
> BUG and WARN'.
> Is the current implemention (an endless loop) desired behavior?
I think it's the most reasonable implementation, otherwise a
function like
int something(void)
{
if (x)
return 0;
else
BUG();
}
will return an uninitialized value.
The arch specific implementations usually just contain a trapping
instruction. With CONFIG_BUG() you get a nice console output
that indicates where this happened, but without CONFIG_BUG(),
this is just reported as an invalid instruction (if CONFIG_PRINTK
is still enabled), killing the current process.
Arnd
Hello Arnd,
On Tuesday, September 25, 2018, 2:06:38 PM CEST Arnd Bergmann wrote:
> We don't really want an empty macro any more, this was used in
> the past, but causes compile-time warnings and undefined behavior
> for no good reason.
Can you elaborate or point me to some other discussion about that undefined behavior?
Best regards,
Alexander
Am 25.09.2018 um 14:20 schrieb Arnd Bergmann:
>
> I think it's the most reasonable implementation, otherwise a
> function like
>
> int something(void)
> {
> if (x)
> return 0;
> else
> BUG();
> }
>
> will return an uninitialized value.
>
> The arch specific implementations usually just contain a trapping
> instruction. With CONFIG_BUG() you get a nice console output
> that indicates where this happened, but without CONFIG_BUG(),
> this is just reported as an invalid instruction (if CONFIG_PRINTK
> is still enabled), killing the current process.
>
> Arnd
>
I see. In that case, you should really update the documentation and help
page of CONFIG_BUG. In its current version it is misleading. It can be
understood as 'It disables that macro completely.'.
Although I know what the purpose of BUG()/BUG_ON() is, I would not
consider the above example as valid C code....
Defining BUG as an endless loop to overcome GCC warnings about not
returning a value is a dirty hack for me.
- Alex
--
Technische Universität Dortmund
Alexander Lochmann PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16 phone: +49.231.7556141
D-44227 Dortmund fax: +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al