Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building with function tracer fails #35

Closed
agners opened this issue Sep 10, 2018 · 24 comments

Comments

@agners
Copy link

commented Sep 10, 2018

Building ARM32 with function tracing enabled currently fails at linking stage:

  LD      vmlinux.o                                                     
                                                                  
  MODPOST vmlinux.o
kernel/softirq.o: In function `_local_bh_enable':
/home/ags/projects/toradex/imx/linux-vanilla-llvm/kernel/softirq.c:152:
undefined reference to `mcount'
kernel/softirq.o: In function `__local_bh_enable_ip':
/home/ags/projects/toradex/imx/linux-vanilla-llvm/kernel/softirq.c:159:
undefined reference to `mcount'
kernel/softirq.o: In function `do_softirq':
/home/ags/projects/toradex/imx/linux-vanilla-llvm/kernel/softirq.c:316:
undefined reference to `mcount'
kernel/softirq.o: In function `irq_enter':
/home/ags/projects/toradex/imx/linux-vanilla-llvm/kernel/softirq.c:337:
undefined reference to `mcount'
kernel/softirq.o: In function `irq_exit':
/home/ags/projects/toradex/imx/linux-vanilla-llvm/kernel/softirq.c:395:
undefined reference to `mcount'
@agners

This comment has been minimized.

Copy link
Author

commented Sep 10, 2018

Adding -meabi gnu allows to compile the kernel, however, it will crash silently on boot, see also:

https://www.spinics.net/lists/arm-kernel/msg671262.html

@m-gupta

This comment has been minimized.

Copy link

commented Sep 12, 2018

Use of "-pg" with "-meabi gnu" on ARM32 is currently known to be broken in clang :-(
https://bugs.llvm.org/show_bug.cgi?id=33845

nathanchance pushed a commit that referenced this issue Nov 9, 2018
Increase kasan instrumented kernel stack size from 32k to 64k. Other
architectures seems to get away with just doubling kernel stack size under
kasan, but on s390 this appears to be not enough due to bigger frame size.
The particular pain point is kasan inlined checks (CONFIG_KASAN_INLINE
vs CONFIG_KASAN_OUTLINE). With inlined checks one particular case hitting
stack overflow is fs sync on xfs filesystem:

 #0 [9a0681e8]  704 bytes  check_usage at 34b1fc
 #1 [9a0684a8]  432 bytes  check_usage at 34c710
 #2 [9a068658]  1048 bytes  validate_chain at 35044a
 #3 [9a068a70]  312 bytes  __lock_acquire at 3559fe
 #4 [9a068ba8]  440 bytes  lock_acquire at 3576ee
 #5 [9a068d60]  104 bytes  _raw_spin_lock at 21b44e0
 #6 [9a068dc8]  1992 bytes  enqueue_entity at 2dbf72
 #7 [9a069590]  1496 bytes  enqueue_task_fair at 2df5f0
 #8 [9a069b68]  64 bytes  ttwu_do_activate at 28f438
 #9 [9a069ba8]  552 bytes  try_to_wake_up at 298c4c
 #10 [9a069dd0]  168 bytes  wake_up_worker at 23f97c
 #11 [9a069e78]  200 bytes  insert_work at 23fc2e
 #12 [9a069f40]  648 bytes  __queue_work at 2487c0
 #13 [9a06a1c8]  200 bytes  __queue_delayed_work at 24db28
 #14 [9a06a290]  248 bytes  mod_delayed_work_on at 24de84
 #15 [9a06a388]  24 bytes  kblockd_mod_delayed_work_on at 153e2a0
 #16 [9a06a3a0]  288 bytes  __blk_mq_delay_run_hw_queue at 158168c
 #17 [9a06a4c0]  192 bytes  blk_mq_run_hw_queue at 1581a3c
 #18 [9a06a580]  184 bytes  blk_mq_sched_insert_requests at 15a2192
 #19 [9a06a638]  1024 bytes  blk_mq_flush_plug_list at 1590f3a
 #20 [9a06aa38]  704 bytes  blk_flush_plug_list at 1555028
 #21 [9a06acf8]  320 bytes  schedule at 219e476
 #22 [9a06ae38]  760 bytes  schedule_timeout at 21b0aac
 #23 [9a06b130]  408 bytes  wait_for_common at 21a1706
 #24 [9a06b2c8]  360 bytes  xfs_buf_iowait at fa1540
 #25 [9a06b430]  256 bytes  __xfs_buf_submit at fadae6
 #26 [9a06b530]  264 bytes  xfs_buf_read_map at fae3f6
 #27 [9a06b638]  656 bytes  xfs_trans_read_buf_map at 10ac9a8
 #28 [9a06b8c8]  304 bytes  xfs_btree_kill_root at e72426
 #29 [9a06b9f8]  288 bytes  xfs_btree_lookup_get_block at e7bc5e
 #30 [9a06bb18]  624 bytes  xfs_btree_lookup at e7e1a6
 #31 [9a06bd88]  2664 bytes  xfs_alloc_ag_vextent_near at dfa070
 #32 [9a06c7f0]  144 bytes  xfs_alloc_ag_vextent at dff3ca
 #33 [9a06c880]  1128 bytes  xfs_alloc_vextent at e05fce
 #34 [9a06cce8]  584 bytes  xfs_bmap_btalloc at e58342
 #35 [9a06cf30]  1336 bytes  xfs_bmapi_write at e618de
 #36 [9a06d468]  776 bytes  xfs_iomap_write_allocate at ff678e
 #37 [9a06d770]  720 bytes  xfs_map_blocks at f82af8
 #38 [9a06da40]  928 bytes  xfs_writepage_map at f83cd6
 #39 [9a06dde0]  320 bytes  xfs_do_writepage at f85872
 #40 [9a06df20]  1320 bytes  write_cache_pages at 73dfe8
 #41 [9a06e448]  208 bytes  xfs_vm_writepages at f7f892
 #42 [9a06e518]  88 bytes  do_writepages at 73fe6a
 #43 [9a06e570]  872 bytes  __writeback_single_inode at a20cb6
 #44 [9a06e8d8]  664 bytes  writeback_sb_inodes at a23be2
 #45 [9a06eb70]  296 bytes  __writeback_inodes_wb at a242e0
 #46 [9a06ec98]  928 bytes  wb_writeback at a2500e
 #47 [9a06f038]  848 bytes  wb_do_writeback at a260ae
 #48 [9a06f388]  536 bytes  wb_workfn at a28228
 #49 [9a06f5a0]  1088 bytes  process_one_work at 24a234
 #50 [9a06f9e0]  1120 bytes  worker_thread at 24ba26
 #51 [9a06fe40]  104 bytes  kthread at 26545a
 #52 [9a06fea8]             kernel_thread_starter at 21b6b62

To be able to increase the stack size to 64k reuse LLILL instruction
in __switch_to function to load 64k - STACK_FRAME_OVERHEAD - __PT_SIZE
(65192) value as unsigned.

Reported-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
@agners

This comment has been minimized.

Copy link
Author

commented Nov 19, 2018

@m-gupta probably depends what the exact definition is of GNU mcount... I guess GCC is the ABI, and Clang/LLVM should follow. And yes, GCC pushes the lr to the stack, see also:

https://www.spinics.net/lists/arm-kernel/msg672631.html

Clang creates the mcount calls in a Function pass in lib/Transforms/Utils/EntryExitInstrumenter.cpp. Afaik, this is at LLVM IR level, it is probably not easy to just insert a push {lr} there.

shenki added a commit to shenki/continuous-integration that referenced this issue Dec 14, 2018
This is required to link the ARM kernel. For details see
ClangBuiltLinux/linux#35.

Signed-off-by: Joel Stanley <joel@jms.id.au>
shenki added a commit to shenki/continuous-integration that referenced this issue Dec 14, 2018
This is required to link the ARM kernel. For details see
ClangBuiltLinux/linux#35.

Signed-off-by: Joel Stanley <joel@jms.id.au>
shenki added a commit to shenki/continuous-integration that referenced this issue Dec 14, 2018
This is required to link the ARM kernel. For details see
ClangBuiltLinux/linux#35.

Signed-off-by: Joel Stanley <joel@jms.id.au>
shenki added a commit to shenki/continuous-integration that referenced this issue Dec 14, 2018
This is required to link the ARM kernel. For details see
ClangBuiltLinux/linux#35.

Signed-off-by: Joel Stanley <joel@jms.id.au>
nathanchance pushed a commit that referenced this issue Dec 26, 2018
The armv8_pmuv3 driver doesn't have a remove function, and when the test
'CONFIG_DEBUG_TEST_DRIVER_REMOVE=y' is enabled, the following Call trace
can be seen.

[    1.424287] Failed to register pmu: armv8_pmuv3, reason -17
[    1.424870] WARNING: CPU: 0 PID: 1 at ../kernel/events/core.c:11771 perf_event_sysfs_init+0x98/0xdc
[    1.425220] Modules linked in:
[    1.425531] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W         4.19.0-rc7-next-20181012-00003-ge7a97b1ad77b-dirty #35
[    1.425951] Hardware name: linux,dummy-virt (DT)
[    1.426212] pstate: 80000005 (Nzcv daif -PAN -UAO)
[    1.426458] pc : perf_event_sysfs_init+0x98/0xdc
[    1.426720] lr : perf_event_sysfs_init+0x98/0xdc
[    1.426908] sp : ffff00000804bd50
[    1.427077] x29: ffff00000804bd50 x28: ffff00000934e078
[    1.427429] x27: ffff000009546000 x26: 0000000000000007
[    1.427757] x25: ffff000009280710 x24: 00000000ffffffef
[    1.428086] x23: ffff000009408000 x22: 0000000000000000
[    1.428415] x21: ffff000009136008 x20: ffff000009408730
[    1.428744] x19: ffff80007b20b400 x18: 000000000000000a
[    1.429075] x17: 0000000000000000 x16: 0000000000000000
[    1.429418] x15: 0000000000000400 x14: 2e79726f74636572
[    1.429748] x13: 696420656d617320 x12: 656874206e692065
[    1.430060] x11: 6d616e20656d6173 x10: 2065687420687469
[    1.430335] x9 : ffff00000804bd50 x8 : 206e6f7361657220
[    1.430610] x7 : 2c3376756d705f38 x6 : ffff00000954d7ce
[    1.430880] x5 : 0000000000000000 x4 : 0000000000000000
[    1.431226] x3 : 0000000000000000 x2 : ffffffffffffffff
[    1.431554] x1 : 4d151327adc50b00 x0 : 0000000000000000
[    1.431868] Call trace:
[    1.432102]  perf_event_sysfs_init+0x98/0xdc
[    1.432382]  do_one_initcall+0x6c/0x1a8
[    1.432637]  kernel_init_freeable+0x1bc/0x280
[    1.432905]  kernel_init+0x18/0x160
[    1.433115]  ret_from_fork+0x10/0x18
[    1.433297] ---[ end trace 27fd415390eb9883 ]---

Rework to set suppress_bind_attrs flag to avoid removing the device when
CONFIG_DEBUG_TEST_DRIVER_REMOVE=y, since there's no real reason to
remove the armv8_pmuv3 driver.

Cc: Arnd Bergmann <arnd@arndb.de>
Co-developed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
shenki added a commit to shenki/continuous-integration that referenced this issue Dec 28, 2018
This is required to link the ARM kernel. For details see
ClangBuiltLinux/linux#35.

Signed-off-by: Joel Stanley <joel@jms.id.au>
shenki added a commit to shenki/continuous-integration that referenced this issue Dec 29, 2018
This is required to link the ARM kernel. For details see
ClangBuiltLinux/linux#35.

Signed-off-by: Joel Stanley <joel@jms.id.au>
@shenki

This comment has been minimized.

Copy link
Member

commented Jan 2, 2019

ppc64 be fails with the same error message:

  AR      built-in.a
  LD      vmlinux.o
  MODPOST vmlinux.o
powerpc64-linux-gnu-ld: init/do_mounts_initrd.o:(__mcount_loc+0x0): undefined reference to `.init_linuxrc'

https://travis-ci.org/shenki/continuous-integration/jobs/474371134#L2813

It can be worked around by disabling ftrace.

@shenki shenki referenced this issue Jan 2, 2019
nathanchance added a commit to nathanchance/linux that referenced this issue Jan 23, 2019
It's broken with Clang.

Link: ClangBuiltLinux#35
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
@nathanchance

This comment has been minimized.

Copy link
Member

commented Feb 15, 2019

FWIW, this, #325 (when using ld.bfd), and #17 (which has patches posted upstream) are the only three issues that prevent successfully building arm allyesconfig on linux-next (and I assume allmodconfig but I haven't tried). I have been working around it with the following patch, I wonder if it is worth trying to upstream... (given that it doesn't seem like this is going to be fixed quickly):

https://github.com/nathanchance/patches/blob/db2abfc9f51d/linux/build-hax/0003-DO-NOT-UPSTREAM-ARM-Don-t-select-HAVE_FUNCTION_TRACE.patch

We currently disable CONFIG_FTRACE for CI, the above change would give us a little extra build coverage.

@nickdesaulniers

This comment has been minimized.

Copy link
Member

commented Feb 17, 2019

CONFIG_FTRACE selects a broken unwinder on arm, @vo4 is looking into this.

@agners

This comment has been minimized.

Copy link
Author

commented Feb 17, 2019

@nickdesaulniers not sure what you mean, on ARM framepointer unwinder doesn't work with Clang, but the ARM EAPI unwinder should work fine. See also: https://patchwork.kernel.org/patch/10614845/

As state above, this is a LLVM issue. LLVM issue https://bugs.llvm.org/show_bug.cgi?id=33845 needs to be resolved, then CONFIG_FTRACE should magically work. Maybe @smithp35 can have a look at it?

We could work around the LLVM issue since Linux uses a custom __gnu_mcount_nc implementation, I actually managed to hack up a version which works when compiling with LLVM/Clang. But not sure if we want such a hack in the kernel.

Another issue is that CONFIG_FUNCTION_GRAPH_TRACER only works with the framepointer unwinder (which does not work on Clang). I think technically a CONFIG_FUNCTION_GRAPH_TRACER which works with the ARM EABI unwinder should be doable, its just that nobody tackled it (yet). Russel would welcome such a change too: https://www.spinics.net/lists/arm-kernel/msg699665.html

@agners

This comment has been minimized.

Copy link
Author

commented Feb 17, 2019

FWIW, this is the patch mentioned above: 0001-HACK-ARM-hack-ftrace-to-work-with-LLVM.patch.gz

@smithp35

This comment has been minimized.

Copy link

commented Feb 18, 2019

I can add that pr to the list of things to look at although I've not got a lot of spare time right now so it may be some time before I can work on it.

@vo4 vo4 self-assigned this Feb 19, 2019
@vo4

This comment has been minimized.

Copy link

commented Feb 19, 2019

We could also resolve this problem by supporting CONFIG_FRAME_POINTER for Clang layout of the frame. In most cases it would only require adding clang-specific offsets from frame pointer to find stuff on the stack. The problem is that backtraces might not be as meaningful, because Clang implementation of AAPCS doesn't push pc register onto the stack.

@vo4

This comment has been minimized.

Copy link

commented Feb 20, 2019

Building CONFIG_FRAME_POINTER for Clang frame layout will end up being essentially a revert of https://lkml.org/lkml/2018/8/26/197, since we'd need a custom mcount function. So getting clang to support "-pg -meabi gnu" is probably the more "correct" approach here.

@nickdesaulniers

This comment has been minimized.

Copy link
Member

commented Apr 25, 2019

@nathanchance

This comment has been minimized.

Copy link
Member

commented Apr 25, 2019

Unfortunately, I was a little preemptive in suggesting that this issue would be avoided with that patch. I still need to disable CONFIG_HAVE_FUNCTION_TRACER to avoid these linking errors :/

@agners

This comment has been minimized.

Copy link
Author

commented Apr 26, 2019

Yeah there is another if !CC_IS_CLANG missing, I mentioned it, but it seems just slightly too late, a couple of hours after the patch got merged:
https://patchwork.kernel.org/patch/10899797/

@nickdesaulniers

This comment has been minimized.

nathanchance pushed a commit that referenced this issue Jul 9, 2019
Dulicate call of null_del_dev() will trigger null pointer error like below.
The reason is a race condition between nullb_device_power_store() and
nullb_group_drop_item().

  CPU#0                         CPU#1
  ----------------              -----------------
  do_rmdir()
   >configfs_rmdir()
    >client_drop_item()
     >nullb_group_drop_item()
                                nullb_device_power_store()
				>null_del_dev()

      >test_and_clear_bit(NULLB_DEV_FL_UP
       >null_del_dev()
       ^^^^^
       Duplicated null_dev_dev() triger null pointer error

				>clear_bit(NULLB_DEV_FL_UP

The fix could be keep the sequnce of clear NULLB_DEV_FL_UP and null_del_dev().

[  698.613600] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
[  698.613608] #PF error: [normal kernel read fault]
[  698.613611] PGD 0 P4D 0
[  698.613619] Oops: 0000 [#1] SMP PTI
[  698.613627] CPU: 3 PID: 6382 Comm: rmdir Not tainted 5.0.0+ #35
[  698.613631] Hardware name: LENOVO 20LJS2EV08/20LJS2EV08, BIOS R0SET33W (1.17 ) 07/18/2018
[  698.613644] RIP: 0010:null_del_dev+0xc/0x110 [null_blk]
[  698.613649] Code: 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b eb 97 e8 47 bb 2a e8 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 54 53 <8b> 77 18 48 89 fb 4c 8b 27 48 c7 c7 40 57 1e c1 e8 bf c7 cb e8 48
[  698.613654] RSP: 0018:ffffb887888bfde0 EFLAGS: 00010286
[  698.613659] RAX: 0000000000000000 RBX: ffff9d436d92bc00 RCX: ffff9d43a9184681
[  698.613663] RDX: ffffffffc11e5c30 RSI: 0000000068be6540 RDI: 0000000000000000
[  698.613667] RBP: ffffb887888bfdf0 R08: 0000000000000001 R09: 0000000000000000
[  698.613671] R10: ffffb887888bfdd8 R11: 0000000000000f16 R12: ffff9d436d92bc08
[  698.613675] R13: ffff9d436d94e630 R14: ffffffffc11e5088 R15: ffffffffc11e5000
[  698.613680] FS:  00007faa68be6540(0000) GS:ffff9d43d14c0000(0000) knlGS:0000000000000000
[  698.613685] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  698.613689] CR2: 0000000000000018 CR3: 000000042f70c002 CR4: 00000000003606e0
[  698.613693] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  698.613697] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  698.613700] Call Trace:
[  698.613712]  nullb_group_drop_item+0x50/0x70 [null_blk]
[  698.613722]  client_drop_item+0x29/0x40
[  698.613728]  configfs_rmdir+0x1ed/0x300
[  698.613738]  vfs_rmdir+0xb2/0x130
[  698.613743]  do_rmdir+0x1c7/0x1e0
[  698.613750]  __x64_sys_rmdir+0x17/0x20
[  698.613759]  do_syscall_64+0x5a/0x110
[  698.613768]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
@Nathan-Huckleberry

This comment has been minimized.

@nathanchance

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

Just for the record, @shenki's PowerPC 64-bit big endian issue is resolved as of v5.3-rc1 with the following commit:

f079bb3c5f2978b2c1a13098ab2a8c32e5d1ee3d is the first fixed commit
commit f079bb3c5f2978b2c1a13098ab2a8c32e5d1ee3d
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date:   Tue May 7 13:31:38 2019 +0000

    powerpc/ftrace: Enable C Version of recordmcount
    
    Selects HAVE_C_RECORDMCOUNT to use the C version of the recordmcount
    intead of the old Perl Version of recordmcount.
    
    This should improve build time. It also seems like the old Perl Version
    misses some calls to _mcount that the C version finds.
    
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

 arch/powerpc/Kconfig | 1 +
 1 file changed, 1 insertion(+)
@nickdesaulniers

This comment has been minimized.

Copy link
Member

commented Aug 16, 2019

https://reviews.llvm.org/rL369147 fixes __gnu_mcount_nc calling convention related errors. (CONFIG_FTRACE)

@nathanchance

This comment has been minimized.

Copy link
Member

commented Aug 20, 2019

I didn't realize this at first but we need something like this

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c3624ca6c0bc..027678b0d4a6 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -112,6 +112,10 @@ ifeq ($(CONFIG_ARM_UNWIND),y)
 CFLAGS_ABI     +=-funwind-tables
 endif
 
+ifeq ($(CONFIG_CC_IS_CLANG),y)
+CFLAGS_ABI     +=-meabi gnu
+endif
+
 # Accept old syntax despite ".syntax unified"
 AFLAGS_NOWARN  :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
 

for there to be no more build errors on arm32 all{yes,mod}config.

@nickdesaulniers

This comment has been minimized.

Copy link
Member

commented Aug 23, 2019

@Nathan-Huckleberry 's unwinder patch got accepted withing 24hrs of submission, nice! 🚀
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8900/1

@nathanchance

This comment has been minimized.

Copy link
Member

commented Aug 29, 2019

Patch sent to finally fix the build error: https://lore.kernel.org/lkml/20190829062635.45609-1-natechancellor@gmail.com/

fengguang pushed a commit to 0day-ci/linux that referenced this issue Aug 29, 2019
The stackframe setup when compiled with clang is different.
Since the stack unwinder expects the gcc stackframe setup it
fails to print backtraces. This patch adds support for the
clang stackframe setup.

Link: ClangBuiltLinux#35

Cc: clang-built-linux@googlegroups.com
Suggested-by: Tri Vo <trong@google.com>
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
fcicq pushed a commit to fcicq/chromiumos-third_party-kernel that referenced this issue Aug 29, 2019
The stackframe setup when compiled with clang is different.
Since the stack unwinder expects the gcc stackframe setup it
fails to print backtraces. This patch adds support for the
clang stackframe setup.

Link: ClangBuiltLinux/linux#35
Cc: clang-built-linux@googlegroups.com
Suggested-by: Tri Vo <trong@google.com>
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
(am from https://lore.kernel.org/patchwork/patch/1118792/)
(also found at https://lkml.kernel.org/r/20190822183022.130790-1-nhuck@google.com)

BUG=chromium:819808
TEST=pre-cq passes

Change-Id: I9135d795c61ba5bb1757cb1c43c106ee58ade1da
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1774708
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
fengguang pushed a commit to 0day-ci/linux that referenced this issue Aug 29, 2019
Currently, multi_v7_defconfig + CONFIG_FUNCTION_TRACER fails to build
with clang:

arm-linux-gnueabi-ld: kernel/softirq.o: in function `_local_bh_enable':
softirq.c:(.text+0x504): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `__local_bh_enable_ip':
softirq.c:(.text+0x58c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `do_softirq':
softirq.c:(.text+0x6c8): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_enter':
softirq.c:(.text+0x75c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_exit':
softirq.c:(.text+0x840): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o:softirq.c:(.text+0xa50): more undefined references to `mcount' follow

clang can emit a working mcount symbol, __gnu_mcount_nc, when
'-meabi gnu' is passed to it. Until r369147 in LLVM, this was
broken and caused the kernel not to boot because the calling
convention was not correct. Now that it is fixed, add this to
the command line when clang is 10.0.0 or newer so everything
works properly.

Link: ClangBuiltLinux#35
Link: https://bugs.llvm.org/show_bug.cgi?id=33845
Link: llvm/llvm-project@16fa8b0
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
fcicq pushed a commit to fcicq/chromiumos-third_party-kernel that referenced this issue Sep 3, 2019
… or newer

Currently, multi_v7_defconfig + CONFIG_FUNCTION_TRACER fails to build
with clang:

arm-linux-gnueabi-ld: kernel/softirq.o: in function `_local_bh_enable':
softirq.c:(.text+0x504): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `__local_bh_enable_ip':
softirq.c:(.text+0x58c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `do_softirq':
softirq.c:(.text+0x6c8): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_enter':
softirq.c:(.text+0x75c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_exit':
softirq.c:(.text+0x840): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o:softirq.c:(.text+0xa50): more undefined references to `mcount' follow

clang can emit a working mcount symbol, __gnu_mcount_nc, when
'-meabi gnu' is passed to it. Until r369147 in LLVM, this was
broken and caused the kernel not to boot with '-pg' because the
calling convention was not correct. Always build with '-meabi gnu'
when using clang but ensure that '-pg' (which is added with
CONFIG_FUNCTION_TRACER and its prereq CONFIG_HAVE_FUNCTION_TRACER)
cannot be added with it unless this is fixed (which means using
clang 10.0.0 and newer).

Link: ClangBuiltLinux/linux#35
Link: https://bugs.llvm.org/show_bug.cgi?id=33845
Link: llvm/llvm-project@16fa8b0
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
(am from https://lore.kernel.org/patchwork/patch/1122525/)
(also found at https://lkml.kernel.org/r/20190831060530.43082-1-natechancellor@gmail.com)

Conflicts:
  arch/arm/Kconfig
    context deltas due to upstream having commit f00790a
    ("ARM: Kconfig: remove useless parenthesis") and CrOS not.

BUG=chromium:819808
TEST=build veyron kernel with clang
  function tracer works

Change-Id: Iccde83e2ed46b9e6f728e379a994691b1f8bcc16
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1783257
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
@nathanchance

This comment has been minimized.

Copy link
Member

commented Sep 4, 2019

@nathanchance

This comment has been minimized.

Copy link
Member

commented Sep 6, 2019

fengguang pushed a commit to 0day-ci/linux that referenced this issue Sep 12, 2019
Currently, multi_v7_defconfig + CONFIG_FUNCTION_TRACER fails to build
with clang:

arm-linux-gnueabi-ld: kernel/softirq.o: in function `_local_bh_enable':
softirq.c:(.text+0x504): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `__local_bh_enable_ip':
softirq.c:(.text+0x58c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `do_softirq':
softirq.c:(.text+0x6c8): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_enter':
softirq.c:(.text+0x75c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_exit':
softirq.c:(.text+0x840): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o:softirq.c:(.text+0xa50): more undefined references to `mcount' follow

clang can emit a working mcount symbol, __gnu_mcount_nc, when
'-meabi gnu' is passed to it. Until r369147 in LLVM, this was
broken and caused the kernel not to boot with '-pg' because the
calling convention was not correct. Always build with '-meabi gnu'
when using clang but ensure that '-pg' (which is added with
CONFIG_FUNCTION_TRACER and its prereq CONFIG_HAVE_FUNCTION_TRACER)
cannot be added with it unless this is fixed (which means using
clang 10.0.0 and newer).

Link: ClangBuiltLinux#35
Link: https://bugs.llvm.org/show_bug.cgi?id=33845
Link: llvm/llvm-project@16fa8b0

Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
@nathanchance

This comment has been minimized.

Copy link
Member

commented Sep 22, 2019

woodsts pushed a commit to woodsts/linux-stable that referenced this issue Oct 7, 2019
[ Upstream commit b0fe66c ]

Currently, multi_v7_defconfig + CONFIG_FUNCTION_TRACER fails to build
with clang:

arm-linux-gnueabi-ld: kernel/softirq.o: in function `_local_bh_enable':
softirq.c:(.text+0x504): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `__local_bh_enable_ip':
softirq.c:(.text+0x58c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `do_softirq':
softirq.c:(.text+0x6c8): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_enter':
softirq.c:(.text+0x75c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_exit':
softirq.c:(.text+0x840): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o:softirq.c:(.text+0xa50): more undefined references to `mcount' follow

clang can emit a working mcount symbol, __gnu_mcount_nc, when
'-meabi gnu' is passed to it. Until r369147 in LLVM, this was
broken and caused the kernel not to boot with '-pg' because the
calling convention was not correct. Always build with '-meabi gnu'
when using clang but ensure that '-pg' (which is added with
CONFIG_FUNCTION_TRACER and its prereq CONFIG_HAVE_FUNCTION_TRACER)
cannot be added with it unless this is fixed (which means using
clang 10.0.0 and newer).

Link: ClangBuiltLinux/linux#35
Link: https://bugs.llvm.org/show_bug.cgi?id=33845
Link: llvm/llvm-project@16fa8b0

Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
woodsts pushed a commit to woodsts/linux-stable that referenced this issue Oct 7, 2019
[ Upstream commit b0fe66c ]

Currently, multi_v7_defconfig + CONFIG_FUNCTION_TRACER fails to build
with clang:

arm-linux-gnueabi-ld: kernel/softirq.o: in function `_local_bh_enable':
softirq.c:(.text+0x504): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `__local_bh_enable_ip':
softirq.c:(.text+0x58c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `do_softirq':
softirq.c:(.text+0x6c8): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_enter':
softirq.c:(.text+0x75c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_exit':
softirq.c:(.text+0x840): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o:softirq.c:(.text+0xa50): more undefined references to `mcount' follow

clang can emit a working mcount symbol, __gnu_mcount_nc, when
'-meabi gnu' is passed to it. Until r369147 in LLVM, this was
broken and caused the kernel not to boot with '-pg' because the
calling convention was not correct. Always build with '-meabi gnu'
when using clang but ensure that '-pg' (which is added with
CONFIG_FUNCTION_TRACER and its prereq CONFIG_HAVE_FUNCTION_TRACER)
cannot be added with it unless this is fixed (which means using
clang 10.0.0 and newer).

Link: ClangBuiltLinux/linux#35
Link: https://bugs.llvm.org/show_bug.cgi?id=33845
Link: llvm/llvm-project@16fa8b0

Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.