[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiJSzSkF-FDcHydR61Q3_q4xCiqq37tfXdijaCxsDF86Q@mail.gmail.com>
Date: Mon, 31 Jul 2023 11:40:04 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Petr Mladek <pmladek@...e.com>
Cc: Tejun Heo <tj@...nel.org>, Dave Airlie <airlied@...il.com>,
Arnd Bergmann <arnd@...db.de>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: arm32 build warnings in workqueue.c
On Mon, 31 Jul 2023 at 01:20, Petr Mladek <pmladek@...e.com> wrote:
>
> Would it help to use const variables?
I guess it would _work_ these days (I think modern C has picked up
what C++ idiom of "const variable with an initializer is a constant"),
although with old compilers I would actually not be at all surprised
to see 'const variable' uses being turned into "load from memory",
But I don't see any real advantage, and it gets very nasty for non-static ones.
I think people just need to expand some things manually if they use a debugger.
It's not like we don't use macros absolutely EVERYWHERE ELSE, and any
gdb user already has to deal with it. The workqueue flags are the
least of your problems.
So I think the whole "gdb debug info" argument is complete garbage,
and was never true at all. If you want gdb to know about these
constants, you just do the same thing that gdb users already have to
do for other things.
We have all those gdb python helper scripts for other kernel magic -
some of it *much* deeper magic than a trivial "combine a few
constants".
And honestly, I don't understand why anybody seriously believes that
those WORK_STRUCT constants are somehow very important. We have many
*much* more fundamental constants that are #define's. Thinking that
WORK_OFFQ_CANCELING needs special gdb understanding when we have
PAGE_SIZE that does not seems entirely crazy to me.
Linus
Powered by blists - more mailing lists