So a tentative suggestion on how to implement this is to add a use flag called "allmodconfig" or similar that the cros-kernel2.eclass looks for and overrides the default configuration.  We could then add this use flag to a board which has this use flag in it's make.conf

I'm not sure if we want the amd64-generic, arm64-generic to use this flag or to make a separate board variant which uses it -- I'm leaning towards using a variant since some people may use the normal *-generic boards.

i think the best route would be to define a new precq config that uses the generic board but injects the new USE flag.  then we can add that to the COMMIT-QUEUE.ini file in the kernel repo.  that wouldn't require messing with any new boards or files in overlays/.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a8369d79f01483c4e7634f814c7bbc6b018e78ff

commit a8369d79f01483c4e7634f814c7bbc6b018e78ff
Author: Guenter Roeck <linux@roeck-us.net>
Date: Thu Oct 05 12:17:03 2017

FROMLIST: scripts/kallsyms: Ignore symbol type 'n'

gcc on aarch64 may emit synbols of type 'n' if the kernel is built with
'-frecord-gcc-switches'. In most cases, those symbols are reported
with nm as
	000000000000000e n $d
and with objdump as
	0000000000000000 l    d  .GCC.command.line	0000000000000000 .GCC.command.line
	000000000000000e l       .GCC.command.line	0000000000000000 $d

Those symbols are detected in is_arm_mapping_symbol() and ignored. However,
if "--prefix-symbols=<prefix>" is configured as well, the situation is
different. For example, in efi/libstub, arm64 images are built with
	'--prefix-alloc-sections=.init --prefix-symbols=__efistub_'.
In combination with '-frecord-gcc-switches', the symbols are now reported
by nm as:
	000000000000000e n __efistub_$d
and by objdump as:
	0000000000000000 l    d  .GCC.command.line	0000000000000000 .GCC.command.line
	000000000000000e l       .GCC.command.line	0000000000000000 __efistub_$d

Those symbols are no longer ignored and included in the base address
calculation. This results in a base address of 000000000000000e, which
in turn causes kallsyms to abort with
    kallsyms failure:
	relative symbol value 0xffffff900800a000 out of range in relative mode

The problem is seen in little endian arm64 builds with CONFIG_EFI enabled
and with '-frecord-gcc-switches' set in KCFLAGS.

Explicitly ignore symbols of type 'n' since those are clearly debug
symbols.

BUG=chromium:722580, chromium:769824 
TEST=Little endian arm64 build with efi enabled

Change-Id: Icd624f8f27d8ab11f9393c8fe477be587a83b61b
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(am from https://patchwork.kernel.org/patch/9985205/)
Reviewed-on: https://chromium-review.googlesource.com/699661
Reviewed-by: Caroline Tice <cmtice@chromium.org>

[modify] https://crrev.com/a8369d79f01483c4e7634f814c7bbc6b018e78ff/scripts/kallsyms.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d52ea05f93e2853d7430763b35ecb70b6db224d2

commit d52ea05f93e2853d7430763b35ecb70b6db224d2
Author: Guenter Roeck <linux@roeck-us.net>
Date: Thu Oct 05 12:17:00 2017

FROMLIST: scripts/kallsyms: Ignore symbol type 'n'

gcc on aarch64 may emit synbols of type 'n' if the kernel is built with
'-frecord-gcc-switches'. In most cases, those symbols are reported
with nm as
	000000000000000e n $d
and with objdump as
	0000000000000000 l    d  .GCC.command.line	0000000000000000 .GCC.command.line
	000000000000000e l       .GCC.command.line	0000000000000000 $d

Those symbols are detected in is_arm_mapping_symbol() and ignored. However,
if "--prefix-symbols=<prefix>" is configured as well, the situation is
different. For example, in efi/libstub, arm64 images are built with
	'--prefix-alloc-sections=.init --prefix-symbols=__efistub_'.
In combination with '-frecord-gcc-switches', the symbols are now reported
by nm as:
	000000000000000e n __efistub_$d
and by objdump as:
	0000000000000000 l    d  .GCC.command.line	0000000000000000 .GCC.command.line
	000000000000000e l       .GCC.command.line	0000000000000000 __efistub_$d

Those symbols are no longer ignored and included in the base address
calculation. This results in a base address of 000000000000000e, which
in turn causes kallsyms to abort with
    kallsyms failure:
	relative symbol value 0xffffff900800a000 out of range in relative mode

The problem is seen in little endian arm64 builds with CONFIG_EFI enabled
and with '-frecord-gcc-switches' set in KCFLAGS.

Explicitly ignore symbols of type 'n' since those are clearly debug
symbols.

BUG=chromium:722580, chromium:769824 
TEST=Little endian arm64 build with efi enabled

Change-Id: Icd624f8f27d8ab11f9393c8fe477be587a83b61b
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(am from https://patchwork.kernel.org/patch/9985205/)
Reviewed-on: https://chromium-review.googlesource.com/701496

[modify] https://crrev.com/d52ea05f93e2853d7430763b35ecb70b6db224d2/scripts/kallsyms.c

Submitted CL:702689 to add the new USE flag. Please review and comment.
Now to precq changes. I had a look, but I don't really understand the build system well enough to know how to add a new precq configuration as suggested on #2. Can someone point me to a similar example, by any chance ?

is there a reason for limiting this to a specific board/config/precq bot ?  why not make it part of src_test and then every dev/precq/cq bot gets it for free ?

#7: Doesn't that mean that an "allmodconfig" build would run for each build for each board, ie potentially multiple times for the same architecture ?

A single allmodconfig build (x86_64, chromeos-4.4) takes 170+ minutes of CPU time on my development system. Granted, that translates to only ~5 minutes realtime, but it adds up. I am already concerned that the three runs necessary for decent coverage (arm,arm64,x86_64) are deemed to be too much, and would be very hesitant to ask for more.

Maybe I misunderstand what you mean; if so, I would appreciate if you can give me some more insight.

it would run in the UnitTest stage for every board, yes, but not in the build phase otherwise.  i guess since allmodconfig basically ignores USE/SPLITCONFIG settings, that extra coverage isn't super useful.

if it takes an extremely long time, that's a good reason to restrict its behavior.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/bc55281a4bd5f11404b95996c73b0d5a04293136

commit bc55281a4bd5f11404b95996c73b0d5a04293136
Author: Guenter Roeck <groeck@chromium.org>
Date: Wed Oct 25 05:48:00 2017

kernel: Add 'buildtest' USE flag

'USE=buildtest' initiates an "allmodconfig" kernel build.
This flag is for use in precq configs.

BUG=chromium:722580
TEST="USE=buildtest emerge-{arm,arm64,amd64}-generic chromeos-kernel-4_{4,12}"

Change-Id: I8cd47495edcf581698c97ca990d14dd840638af8
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/702689
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/bc55281a4bd5f11404b95996c73b0d5a04293136/sys-kernel/chromeos-kernel-3_10/chromeos-kernel-3_10-9999.ebuild
[modify] https://crrev.com/bc55281a4bd5f11404b95996c73b0d5a04293136/sys-kernel/chromeos-kernel-3_18/chromeos-kernel-3_18-9999.ebuild
[modify] https://crrev.com/bc55281a4bd5f11404b95996c73b0d5a04293136/eclass/cros-kernel2.eclass
[modify] https://crrev.com/bc55281a4bd5f11404b95996c73b0d5a04293136/sys-kernel/chromeos-kernel-3_14/chromeos-kernel-3_14-9999.ebuild
[modify] https://crrev.com/bc55281a4bd5f11404b95996c73b0d5a04293136/sys-kernel/chromeos-kernel-4_12/chromeos-kernel-4_12-9999.ebuild
[modify] https://crrev.com/bc55281a4bd5f11404b95996c73b0d5a04293136/sys-kernel/chromeos-kernel-4_4/chromeos-kernel-4_4-9999.ebuild