On Thu, Mar 18, 2021 at 05:07:06PM -0700, Nick Desaulniers wrote:
> GDB produces the following warning when debugging kernels built with
> CONFIG_RELR:
>
> BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn'
>
> when loading a kernel built with CONFIG_RELR into GDB. It can
GDB produces the following warning when debugging kernels built with
CONFIG_RELR:
BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn'
when loading a kernel built with CONFIG_RELR into GDB. It can also
prevent debugging symbols using such relocations.
Peter sugguests:
[Th
From: Nick Desaulniers
> Sent: 12 March 2021 17:55
>
> On Thu, Mar 11, 2021 at 5:09 PM Nick Desaulniers
> wrote:
> >
> > -Wframe-larger-than= requires stack frame information, which the
> > frontend cannot provide. This diagnostic is emitted late during
> > compilation once stack frame size is av
On Fri, Mar 12, 2021 at 9:55 AM Nick Desaulniers
wrote:
>
> On Thu, Mar 11, 2021 at 5:09 PM Nick Desaulniers
> wrote:
> >
> > -Wframe-larger-than= requires stack frame information, which the
> > frontend cannot provide. This diagnostic is emitted late during
> > compilation once stack frame size
On Thu, Mar 11, 2021 at 5:09 PM Nick Desaulniers
wrote:
>
> -Wframe-larger-than= requires stack frame information, which the
> frontend cannot provide. This diagnostic is emitted late during
> compilation once stack frame size is available.
>
> When building with LTO, the frontend simply lowers C
-Wframe-larger-than= requires stack frame information, which the
frontend cannot provide. This diagnostic is emitted late during
compilation once stack frame size is available.
When building with LTO, the frontend simply lowers C to LLVM IR and does
not have stack frame information, so it cannot e
On Wed, Feb 24, 2021 at 12:14:04PM +0900, Masahiro Yamada wrote:
> On Sat, Feb 6, 2021 at 12:46 PM Sedat Dilek wrote:
> >
> > On Sat, Feb 6, 2021 at 2:49 AM Masahiro Yamada wrote:
> > >
> > > On Sat, Feb 6, 2021 at 7:01 AM 'Nick Desaulniers' via Clang Built
> > > Linux wrote:
> > > >
> > > > I n
On Sat, Feb 6, 2021 at 12:46 PM Sedat Dilek wrote:
>
> On Sat, Feb 6, 2021 at 2:49 AM Masahiro Yamada wrote:
> >
> > On Sat, Feb 6, 2021 at 7:01 AM 'Nick Desaulniers' via Clang Built
> > Linux wrote:
> > >
> > > I noticed we're invoking $(CC) via $(shell) more than once to check the
> > > versio
On Wed, Feb 24, 2021 at 5:10 AM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> On Fri, Feb 5, 2021 at 5:49 PM Masahiro Yamada wrote:
> >
> > On Sat, Feb 6, 2021 at 7:01 AM 'Nick Desaulniers' via Clang Built
> > Linux wrote:
> > >
> > > I noticed we're invoking $(CC) via $(shell) more than o
On Fri, Feb 5, 2021 at 5:49 PM Masahiro Yamada wrote:
>
> On Sat, Feb 6, 2021 at 7:01 AM 'Nick Desaulniers' via Clang Built
> Linux wrote:
> >
> > I noticed we're invoking $(CC) via $(shell) more than once to check the
> > version. Let's reuse the first string captured in $CC_VERSION_TEXT.
> >
>
On Wed, Feb 17, 2021 at 6:33 AM Nathan Chancellor wrote:
>
> When using AMD's Optimizing C/C++ Compiler (AOCC), the build fails due
> to a # character in the version string, which is interpreted as a
> comment:
>
> $ make CC=clang defconfig init/main.o
> include/config/auto.conf.cmd:1374: *** inva
When using AMD's Optimizing C/C++ Compiler (AOCC), the build fails due
to a # character in the version string, which is interpreted as a
comment:
$ make CC=clang defconfig init/main.o
include/config/auto.conf.cmd:1374: *** invalid syntax in conditional. Stop.
$ sed -n 1374p include/config/auto.co
On Sat, Feb 6, 2021 at 2:49 AM Masahiro Yamada wrote:
>
> On Sat, Feb 6, 2021 at 7:01 AM 'Nick Desaulniers' via Clang Built
> Linux wrote:
> >
> > I noticed we're invoking $(CC) via $(shell) more than once to check the
> > version. Let's reuse the first string captured in $CC_VERSION_TEXT.
> >
>
On Sat, Feb 6, 2021 at 7:01 AM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> I noticed we're invoking $(CC) via $(shell) more than once to check the
> version. Let's reuse the first string captured in $CC_VERSION_TEXT.
>
> Fixes: 315bab4e972d ("kbuild: fix endless syncconfig in case arch Ma
I noticed we're invoking $(CC) via $(shell) more than once to check the
version. Let's reuse the first string captured in $CC_VERSION_TEXT.
Fixes: 315bab4e972d ("kbuild: fix endless syncconfig in case arch Makefile sets
CROSS_COMPILE")
Signed-off-by: Nick Desaulniers
---
Makefile | 14 +++-
On Tue, Dec 22, 2020 at 12:00 PM Tiezhu Yang wrote:
>
> Module.symvers still exists when make clean, remove it.
>
> Signed-off-by: Tiezhu Yang
NACK.
Module.symver is removed by "make mrproper"
since it is needed for building external modules.
> ---
> Makefile | 2 +-
> 1 file changed, 1 in
Module.symvers still exists when make clean, remove it.
Signed-off-by: Tiezhu Yang
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index e30cf02..8235bb7 100644
--- a/Makefile
+++ b/Makefile
@@ -1468,7 +1468,7 @@ endif # CONFIG_MODULES
# Di
On Thu, Dec 17, 2020 at 09:47:07PM +0900, Masahiro Yamada wrote:
> I do not want to touch scripts/kconfig/Makefile
> every time somebody adds a new file to
> kernel/configs/*.config or arch/$(ARCH)/configs/*.config
Because that happens so often and somehow burdens your maintenance
effort impossibl
On Thu, Dec 17, 2020 at 9:18 PM Borislav Petkov wrote:
>
> From: Borislav Petkov
>
> Add the targets which add Kconfig items to the .config so that the
> kernel can be run as a guest, to the main 'make help' output so that
> they can be found easier and there's no need to grep the tree each time
From: Borislav Petkov
Add the targets which add Kconfig items to the .config so that the
kernel can be run as a guest, to the main 'make help' output so that
they can be found easier and there's no need to grep the tree each time
to remember what they should be called.
Signed-off-by: Borislav Pe
`make help' outputs more than a screenfull of lines.
In case a user has PAGER defined in his environment, she most likely
wants it to be used in such situations.
Signed-off-by: Dirk Gouders
---
Makefile | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Makefile b/Makefile
index 992d244
On Thu, Sep 3, 2020 at 7:40 AM Nick Desaulniers wrote:
>
> On Fri, Aug 21, 2020 at 10:14 PM Masahiro Yamada wrote:
> >
> > On Fri, Aug 21, 2020 at 7:10 AM 'Nick Desaulniers' via Clang Built
> > Linux wrote:
> > >
> > > While moving Android kernels over to use LLVM=1, we observe the failure
> > >
On Fri, Aug 21, 2020 at 10:14 PM Masahiro Yamada wrote:
>
> On Fri, Aug 21, 2020 at 7:10 AM 'Nick Desaulniers' via Clang Built
> Linux wrote:
> >
> > While moving Android kernels over to use LLVM=1, we observe the failure
> > when building in a hermetic docker image:
> > HOSTCC scripts/basic/f
On Fri, Aug 21, 2020 at 7:10 AM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> While moving Android kernels over to use LLVM=1, we observe the failure
> when building in a hermetic docker image:
> HOSTCC scripts/basic/fixdep
> clang: error: unable to execute command: Executable "ld" doesn'
On Thu, Aug 20, 2020 at 03:09:55PM -0700, 'Nick Desaulniers' via Clang Built
Linux wrote:
> While moving Android kernels over to use LLVM=1, we observe the failure
> when building in a hermetic docker image:
> HOSTCC scripts/basic/fixdep
> clang: error: unable to execute command: Executable "ld
While moving Android kernels over to use LLVM=1, we observe the failure
when building in a hermetic docker image:
HOSTCC scripts/basic/fixdep
clang: error: unable to execute command: Executable "ld" doesn't exist!
The is because the build of the host utility fixdep builds the fixdep
executable
The quick RFC patch I just proposed in the parent email is
broken in its implementation. I will submit an updated
version soon.
Michael Witten (Tue, 18 Aug 2020 22:05:00 -):
> I think there's an important distinction to make between
> the following 2 kinds of code:
>
> * The curated code pe
I think there's an important distinction to make between
the following 2 kinds of code:
* The curated code people just want to build.
* The new patches that maintainers are reviewing.
Certainly, maintainers should have a wide range of tools
at their disposal to probe the quality of a patch; t
> I'm a big fan of -Wdeclaration-after-statement and I think C++ style
> mixed variables/statements code has several disadvantages:
Agreed.
Personally I think declarations should either be either right
at the top of a function or in a very small code block.
Otherwise they are annoying to find.
Y
* Linus Torvalds wrote:
> On Mon, Aug 17, 2020 at 3:09 PM Pavel Machek wrote:
> >
> > Submitter believes "wild variable placement" can help with
> > #ifdefs.. and that may be actually good tradeoff.
>
> I agree that it can help in some cases.
>
> But it can also make it really hard to find t
On Mon, Aug 17, 2020 at 3:09 PM Pavel Machek wrote:
>
> Submitter believes "wild variable placement" can help with
> #ifdefs.. and that may be actually good tradeoff.
I agree that it can help in some cases.
But it can also make it really hard to find the variable declarations
in other cases. I'v
On Mon 2020-08-17 14:29:37, Linus Torvalds wrote:
> On Mon, Aug 17, 2020 at 2:15 PM Eric W. Biederman
> wrote:
> >
> > Does anyone remember why we added this warning? I had always thought
> > it's purpose was to ensure we stayed within our chosen dialect of C.
>
> As far as I'm concerned, that'
On Mon, Aug 17, 2020 at 2:15 PM Eric W. Biederman wrote:
>
> Does anyone remember why we added this warning? I had always thought
> it's purpose was to ensure we stayed within our chosen dialect of C.
As far as I'm concerned, that's the primary motivation.
I'm not seeing why we'd suddenly allow
Pavel Machek writes:
> Hi!
>
>> > This is not just a matter of style; this is a matter of semantics,
>> > especially with regard to:
>> >
>> > * const Correctness.
>> > A const-declared variable must be initialized when defined.
>> >
>> > * Conditional Compilation.
>> > When there i
Hi!
> > This is not just a matter of style; this is a matter of semantics,
> > especially with regard to:
> >
> > * const Correctness.
> > A const-declared variable must be initialized when defined.
> >
> > * Conditional Compilation.
> > When there is complex interaction between comp
On Sun 2020-08-16 21:19:23, Joe Perches wrote:
> On Mon, 2020-08-17 at 03:37 +, Michael Witten wrote:
> > Matters of style should probably not be enforced by the build
> > infrastructure; style is a matter for the maintainer to enforce:
>
> I rather doubt style advice should be taken from
Joe Perches (Sun, 16 Aug 2020 10:56:53 -0700):
> On Mon, 2020-08-17 at 03:37 +, Michael Witten wrote:
>> Matters of style should probably not be enforced by
>> the build infrastructure; style is a matter for the
>> maintainer to enforce:
>
> I rather doubt style advice should be tak
On Mon, 2020-08-17 at 03:37 +, Michael Witten wrote:
> Matters of style should probably not be enforced by the build
> infrastructure; style is a matter for the maintainer to enforce:
I rather doubt style advice should be taken from someone who
right justifies fixed pitch block text.
chee
Joe Perches (Sun, 16 Aug 2020 10:56:53 -0700):
> I rather prefer block declarations instead of
> sprinkling declarations around with code.
Hey, we all have our guilty pleasures.
Fortunately, even with this patch, you'd still be able to indulge
in your preferred style, or even enforce it among co
On Sun, 2020-08-16 at 16:35 +, Michael Witten wrote:
> Requiring every declaration to be at the top of a block is an
> antiquated, vestigial naivete from a time when C was just a
> glorified abstraction over conventional patterns in assembly
> programming.
I rather prefer block declarations in
On Sun, Aug 16, 2020 at 04:35:00PM -, Michael Witten wrote:
> This is not just a matter of style; this is a matter of semantics,
> especially with regard to:
>
> * const Correctness.
> A const-declared variable must be initialized when defined.
>
> * Conditional Compilation.
> Whe
This is not just a matter of style; this is a matter of semantics,
especially with regard to:
* const Correctness.
A const-declared variable must be initialized when defined.
* Conditional Compilation.
When there is complex interaction between compile-time
configuration options, i
On Thu, Jul 23, 2020 at 05:57:04PM -0700, Andrew Morton wrote:
> On Thu, 23 Jul 2020 14:29:33 +0800 Feng Tang wrote:
>
> > > > gcc has an option '-falign-functions=n' to force text aligned, and with
> > > > that option enabled, some of those performance changes will be gone,
> > > > like [1][2][3
On Thu, 23 Jul 2020 14:29:33 +0800 Feng Tang wrote:
> > > gcc has an option '-falign-functions=n' to force text aligned, and with
> > > that option enabled, some of those performance changes will be gone,
> > > like [1][2][3].
> > >
> > > Add this option so that developers and 0day can easily fi
On Wed, Jul 22, 2020 at 08:39:19PM -0700, Andrew Morton wrote:
> On Thu, 23 Jul 2020 11:30:01 +0800 Feng Tang wrote:
>
> > Recently 0day reported many strange performance changes (regression
> > or improvement), in which there was no obvious relation between
> > the culprit commit and the benchma
Hi Andrew,
Thanks for the review.
On Wed, Jul 22, 2020 at 08:39:19PM -0700, Andrew Morton wrote:
> On Thu, 23 Jul 2020 11:30:01 +0800 Feng Tang wrote:
>
> > Recently 0day reported many strange performance changes (regression
> > or improvement), in which there was no obvious relation between
>
On Thu, 23 Jul 2020 11:30:01 +0800 Feng Tang wrote:
> Recently 0day reported many strange performance changes (regression
> or improvement), in which there was no obvious relation between
> the culprit commit and the benchmark at the first look, and it causes
> people to doubt the test itself is
Recently 0day reported many strange performance changes (regression
or improvement), in which there was no obvious relation between
the culprit commit and the benchmark at the first look, and it causes
people to doubt the test itself is wrong.
Upon further check, many of these cases are caused by
On 2020-07-20, Nick Desaulniers wrote:
On Mon, Jul 20, 2020 at 11:16 AM Nathan Chancellor
wrote:
On Mon, Jul 20, 2020 at 11:12:22AM -0700, Fangrui Song wrote:
> When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if
> $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-,
> GCC_TOOL
On Mon, Jul 20, 2020 at 11:16 AM Nathan Chancellor
wrote:
>
> On Mon, Jul 20, 2020 at 11:12:22AM -0700, Fangrui Song wrote:
> > When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if
> > $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-,
> > GCC_TOOLCHAIN_DIR will be set to /usr/bin
On Mon, Jul 20, 2020 at 11:12:22AM -0700, Fangrui Song wrote:
> When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if
> $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-,
> GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to
> /usr/bin/ and Clang as of 11 will sear
When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if
$(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-,
GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to
/usr/bin/ and Clang as of 11 will search for both
$(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle.
I am doing eudyptula assigned tasks to get selected as a mentee. I am using
LDF103 course knowledge and loving it.
I used git log for Makefile and ran checkpatch.pl on my patch as to follow the
same commit process guidelines. I hope you will like it.
Signed-off-by: Dhiraj Sharma
Suggested-by: L
On Thu, Jun 11, 2020 at 02:09:21PM -0700, Nick Desaulniers wrote:
> On Wed, Jun 10, 2020 at 4:30 PM Arvind Sankar wrote:
> >
> > Yes, the gcc driver reports an error when deciding what to pass to the
> > assembler for -gz=zlib, if it was configured with a linker that does not
> > support the flag.
On Thu, Jun 11, 2020 at 01:44:53PM -0700, Nick Desaulniers wrote:
> On Wed, Jun 10, 2020 at 4:39 PM Arvind Sankar wrote:
> >
> > On Wed, Jun 10, 2020 at 07:30:46PM -0400, Arvind Sankar wrote:
> > > On Wed, Jun 10, 2020 at 02:27:55PM -0700, Nick Desaulniers wrote:
> > >
> > > No, as-option does inv
On Wed, Jun 10, 2020 at 4:30 PM Arvind Sankar wrote:
>
> On Wed, Jun 10, 2020 at 02:27:55PM -0700, Nick Desaulniers wrote:
> > On Wed, Jun 10, 2020 at 12:11 PM Arvind Sankar
> > wrote:
> > >
> > > Commit
> > > 10e68b02c861 ("Makefile: support compressed debug info")
> > > added support for com
On Wed, Jun 10, 2020 at 4:39 PM Arvind Sankar wrote:
>
> On Wed, Jun 10, 2020 at 07:30:46PM -0400, Arvind Sankar wrote:
> > On Wed, Jun 10, 2020 at 02:27:55PM -0700, Nick Desaulniers wrote:
> >
> > No, as-option does invoke the assembler. The problem here is that with
> > -Wa, the option is only s
On Wed, Jun 10, 2020 at 07:30:46PM -0400, Arvind Sankar wrote:
> On Wed, Jun 10, 2020 at 02:27:55PM -0700, Nick Desaulniers wrote:
>
> No, as-option does invoke the assembler. The problem here is that with
> -Wa, the option is only seen by the assembler, not the gcc driver. So it
> will succeed be
On Wed, Jun 10, 2020 at 02:27:55PM -0700, Nick Desaulniers wrote:
> On Wed, Jun 10, 2020 at 12:11 PM Arvind Sankar wrote:
> >
> > Commit
> > 10e68b02c861 ("Makefile: support compressed debug info")
> > added support for compressed debug sections.
> >
> > Support is detected by checking
> > - doe
On Wed, Jun 10, 2020 at 12:11 PM Arvind Sankar wrote:
>
> Commit
> 10e68b02c861 ("Makefile: support compressed debug info")
> added support for compressed debug sections.
>
> Support is detected by checking
> - does the compiler support -gz=zlib
> - does the assembler support --compressed-debug-
Commit
10e68b02c861 ("Makefile: support compressed debug info")
added support for compressed debug sections.
Support is detected by checking
- does the compiler support -gz=zlib
- does the assembler support --compressed-debug-sections=zlib
- does the linker support --compressed-debug-sections=zl
Hi Nick,
> + Nick, H.J.
> I'm unfamiliar with the git tag conventions of binutils. Does a patch
> that landed in 2.25.51.0.4 mean it shipped in the official 2.25
> release, or 2.26 release? Specifically, commit 19a7fe52ae3d.
2.26.
The convention is that a released form of the binutils has a ve
On Tue, May 12, 2020 at 1:01 PM Fangrui Song wrote:
>
> >Fangrui, I wasn't able to easily find what version of binutils first
> >added support. Can you please teach me how to fish?
>
> I actually downloaded https://ftp.gnu.org/gnu/binutils/ archives and
> located the sources... I think an easier
On Wed, May 13, 2020 at 4:52 AM Masahiro Yamada wrote:
>
> Nick,
>
> On Wed, May 13, 2020 at 4:23 AM Nick Desaulniers
> wrote:
> >
> > On Mon, May 11, 2020 at 10:54 PM Masahiro Yamada
> > wrote:
> > >
> > > > >On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers
> > > > > wrote:
> > > > >>
> > > > >
Nick,
On Wed, May 13, 2020 at 4:23 AM Nick Desaulniers
wrote:
>
> On Mon, May 11, 2020 at 10:54 PM Masahiro Yamada wrote:
> >
> > > >On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers
> > > > wrote:
> > > >>
> > > >> As debug information gets larger and larger, it helps significantly
> > > >> save
On Tue, May 12, 2020 at 10:01 PM Fangrui Song wrote:
>
> On 2020-05-12, Nick Desaulniers wrote:
...
> >I have a patch series that enables dwarf5 support in the kernel that
> >I'm working up to. I wanted to send this first. Both roughly reduce
> >the debug info size by 20% each, though I haven't
On Tue, May 12, 2020 at 9:23 PM Nick Desaulniers
wrote:
>
> On Mon, May 11, 2020 at 10:54 PM Masahiro Yamada wrote:
> >
> > > >On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers
> > > > wrote:
> > > >>
> > > >> As debug information gets larger and larger, it helps significantly
> > > >> save
> > >
On 2020-05-12, Nick Desaulniers wrote:
On Mon, May 11, 2020 at 10:54 PM Masahiro Yamada wrote:
> >On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers
> > wrote:
> >>
> >> As debug information gets larger and larger, it helps significantly save
> >> the size of vmlinux images to compress the inform
On Mon, May 11, 2020 at 10:54 PM Masahiro Yamada wrote:
>
> > >On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers
> > > wrote:
> > >>
> > >> As debug information gets larger and larger, it helps significantly save
> > >> the size of vmlinux images to compress the information in the debug
> > >> infor
On Tue, May 12, 2020 at 7:47 AM Masahiro Yamada wrote:
>
> Hi Sedat,
>
>
> On Tue, May 5, 2020 at 1:25 AM Sedat Dilek wrote:
> >
> > On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers
> > wrote:
> > >
> > > As debug information gets larger and larger, it helps significantly save
> > > the size of v
On Tue, May 5, 2020 at 9:47 AM Fangrui Song wrote:
>
>
> On 2020-05-04, Sedat Dilek wrote:
> >On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers
> > wrote:
> >>
> >> As debug information gets larger and larger, it helps significantly save
> >> the size of vmlinux images to compress the information in
Hi Sedat,
On Tue, May 5, 2020 at 1:25 AM Sedat Dilek wrote:
>
> On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers
> wrote:
> >
> > As debug information gets larger and larger, it helps significantly save
> > the size of vmlinux images to compress the information in the debug
> > information secti
On 2020-05-04, Sedat Dilek wrote:
On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers
wrote:
As debug information gets larger and larger, it helps significantly save
the size of vmlinux images to compress the information in the debug
information sections. Note: this debug info is typically split
On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers
wrote:
>
> As debug information gets larger and larger, it helps significantly save
> the size of vmlinux images to compress the information in the debug
> information sections. Note: this debug info is typically split off from
> the final compressed
As debug information gets larger and larger, it helps significantly save
the size of vmlinux images to compress the information in the debug
information sections. Note: this debug info is typically split off from
the final compressed kernel image, which is why vmlinux is what's used
in conjunction
On 8/29/19 7:02 AM, Michal Suchanek wrote:
> From gcc documentation:
>
> -Wimplicit-fallthrough=0
> disables the warning altogether.
> -Wimplicit-fallthrough=1
> matches .* regular expression, any comment is used as fallthrough comment.
> -Wimplicit-fallthrough=2
> case insensitively matc
On Fri, Aug 30, 2019 at 1:09 PM Joe Perches wrote:
>
> On Thu, 2019-08-29 at 14:02 +0200, Michal Suchanek wrote:
> > In particular the default value of 3 does not match the comments like
> > /* falls through to do foobar */
>
> How many comments are there like this in the kernel?
+1 Given we are
On Thu, 2019-08-29 at 14:02 +0200, Michal Suchanek wrote:
> In particular the default value of 3 does not match the comments like
> /* falls through to do foobar */
How many comments are there like this in the kernel?
Also you have to deal with gcc/clang differences.
As far as I know, clang doesn
>From gcc documentation:
-Wimplicit-fallthrough=0
disables the warning altogether.
-Wimplicit-fallthrough=1
matches .* regular expression, any comment is used as fallthrough comment.
-Wimplicit-fallthrough=2
case insensitively matches .*falls?[ \t-]*thr(ough|u).* regular expression.
-Wimplic
Hi Linus,
On Wed, Aug 21, 2019 at 2:41 AM Linus Torvalds
wrote:
> On Tue, Aug 20, 2019 at 4:37 PM Joe Perches wrote:
> > > So I'm putting my foot down on yet another broken string copy
> > > interface from people who do not understand this fundamental issue.
> >
> > I think you are mistaken abou
On Tue, Aug 20, 2019 at 05:43:27PM -0700, Linus Torvalds wrote:
> I would seriously suggest doing something like
>
>copy_string( dst, dstsize, src, srcsize, FLAGS );
>
> where FLAGS migth be "pad" or whatever. Make it return the size of the
> resulting string, because while it can be convenie
On Tue, Aug 20, 2019 at 5:20 PM Joe Perches wrote:
>
> Umm, btw: have you actually looked at stracpy?
Yes, Joe, I have.
What part of "there are now so many of them that no human being can
keep track of them" didn't you see as a problem?
How many broken string functions are we going to do, addin
On Tue, Aug 20, 2019 at 4:37 PM Joe Perches wrote:
>
> > So I'm putting my foot down on yet another broken string copy
> > interface from people who do not understand this fundamental issue.
>
> I think you are mistaken about the stracpy limits as
> the only limit is not the source size but the de
Hi Joe,
On Mon, 19 Aug 2019 17:08:00 -0700 Joe Perches wrote:
>
> A few examples:
>
> 1: a patch just to MAINTAINERS done via bash script:
>
> https://lore.kernel.org/lkml/904551f1f198ffac9a0f9c3c99aa966b0a7c76c1.ca...@perches.com/
>
> $ git grep -h "^[FX]:" MAINTAINERS | \
> cut -f2- | grep
On Tue, 2019-08-20 at 16:28 -0700, Linus Torvalds wrote:
> On Mon, Aug 19, 2019 at 5:08 PM Joe Perches wrote:
> > 2: would be Julia Lawall's stracpy change done
> > with coccinelle: (attached)
>
> I'm not actually convinced about stracpy() and friends.
>
> It seems to be yet another badly though
On Tue, 2019-08-20 at 16:28 -0700, Linus Torvalds wrote:
> On Mon, Aug 19, 2019 at 5:08 PM Joe Perches wrote:
> > 2: would be Julia Lawall's stracpy change done
> > with coccinelle: (attached)
>
> I'm not actually convinced about stracpy() and friends.
>
> It seems to be yet another badly though
On Mon, Aug 19, 2019 at 5:08 PM Joe Perches wrote:
>
> 2: would be Julia Lawall's stracpy change done
> with coccinelle: (attached)
I'm not actually convinced about stracpy() and friends.
It seems to be yet another badly thought out string interface, and
there are now so many of them that no hum
On Tue, 2019-08-20 at 09:24 +1000, Stephen Rothwell wrote:
> Hi Joe,
Hi Stephen
> Sorry for the slow response.
No worries. thanks for picking up the thread.
> On Fri, 16 Aug 2019 12:58:27 -0700 Joe Perches wrote:
> > On Sat, 2019-08-10 at 13:33 -0700, Joe Perches wrote:
> > > On Sat, 2019-08-1
Hi Joe,
Sorry for the slow response.
On Fri, 16 Aug 2019 12:58:27 -0700 Joe Perches wrote:
>
> On Sat, 2019-08-10 at 13:33 -0700, Joe Perches wrote:
> > On Sat, 2019-08-10 at 13:18 -0700, Joe Perches wrote:
> []
> > > There are classes of patches generated by scripts that have
> > > no real me
On Sat, 2019-08-10 at 13:33 -0700, Joe Perches wrote:
> On Sat, 2019-08-10 at 13:18 -0700, Joe Perches wrote:
[]
> > There are classes of patches generated by scripts that have
> > no real mechanism to be applied today.
> >
> > For instance: global coccinelle scripted changes to use stracpy
> > ht
(adding Vivien Didelot for vim)
On Wed, 2019-08-14 at 19:44 -0700, Joe Perches wrote:
> On Tue, 2019-08-13 at 14:44 +0200, Miguel Ojeda wrote:
> > Hm... I would go for either __fallthrough as the rest of attributes,
> > or simply fallthrough -- FALLTHROUGH seems wrong. If you want it that
> > way
On Tue, 2019-08-13 at 14:44 +0200, Miguel Ojeda wrote:
> Hm... I would go for either __fallthrough as the rest of attributes,
> or simply fallthrough -- FALLTHROUGH seems wrong. If you want it that
> way for visibility, then I would choose __fallthrough, since the
> underscores are quite prominent
On Mon, Aug 12, 2019 at 6:29 PM Nick Desaulniers
wrote:
>
> On Sat, Aug 10, 2019 at 8:06 PM Joe Perches wrote:
> >
> > On Sat, 2019-08-10 at 19:04 -0700, Nathan Chancellor wrote:
> > > On a tangential note, how are you planning on doing the fallthrough
> > > comment to attribute conversion? The r
On Mon, 2019-08-12 at 09:28 -0700, Nick Desaulniers wrote:
> Isn't [[fallthrough]] the C++ style attribute?
double brackets will likely at some point become the default
attribute style for c as well. It is not now though and
linux will continue to support gcc 7+ and the __attribute__
style for qu
On Sat, Aug 10, 2019 at 8:06 PM Joe Perches wrote:
>
> On Sat, 2019-08-10 at 19:04 -0700, Nathan Chancellor wrote:
> > On a tangential note, how are you planning on doing the fallthrough
> > comment to attribute conversion? The reason I ask is clang does not
> > support the comment annotations, me
On Sat, 2019-08-10 at 20:54 -0700, Joe Perches wrote:
> On Sat, 2019-08-10 at 20:17 -0700, Nathan Chancellor wrote:
> > On Sat, Aug 10, 2019 at 08:06:05PM -0700, Joe Perches wrote:
> > > On Sat, 2019-08-10 at 19:04 -0700, Nathan Chancellor wrote:
> > > > On a tangential note, how are you planning o
On 11/08/2019 05:17, Nathan Chancellor wrote:
> On Sat, Aug 10, 2019 at 08:06:05PM -0700, Joe Perches wrote:
>> On Sat, 2019-08-10 at 19:04 -0700, Nathan Chancellor wrote:
>>> On a tangential note, how are you planning on doing the fallthrough
>>> comment to attribute conversion? The reason I ask i
On Sat, 2019-08-10 at 20:17 -0700, Nathan Chancellor wrote:
> On Sat, Aug 10, 2019 at 08:06:05PM -0700, Joe Perches wrote:
> > On Sat, 2019-08-10 at 19:04 -0700, Nathan Chancellor wrote:
> > > On a tangential note, how are you planning on doing the fallthrough
> > > comment to attribute conversion?
On Sat, Aug 10, 2019 at 08:06:05PM -0700, Joe Perches wrote:
> On Sat, 2019-08-10 at 19:04 -0700, Nathan Chancellor wrote:
> > On a tangential note, how are you planning on doing the fallthrough
> > comment to attribute conversion? The reason I ask is clang does not
> > support the comment annotati
On Sat, 2019-08-10 at 19:04 -0700, Nathan Chancellor wrote:
> On a tangential note, how are you planning on doing the fallthrough
> comment to attribute conversion? The reason I ask is clang does not
> support the comment annotations, meaning that when Nathan Huckleberry's
> patch is applied to cla
1 - 100 of 254 matches
Mail list logo
