undefined reference to `__bad_udelay' while compiling kernel

[Michael]

Hi,

im compiling an exynos kernel with the latest clang toolchain found here https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/refs/heads/master with clang-r353983b (9.0.2 based on r353983b).

I've tried to build my own clang tc and the problem still persists, kernel source can be found here http://opensource.samsung.com , search code SM-G950F G950FXXU4CRK1

Error log captured after "LD init/built-in.o stage"

drivers/built-in.o: In function `displayport_full_link_training':

/home/vaughn/android/dream/drivers/video/fbdev/exynos/dpu/displayport_drv.c:403: undefined reference to `__bad_udelay'

Someone mind helping me with this matter? 

Thanks!

[Michael]

Oh also, this doesnt happened with clang 8 and below

[Pirama Arumuga Nainar]

http://patchwork.ozlabs.org/patch/37903/:

> According to the comment in arch/arm/include/asm/delay.h, __bad_udelay

is specifically designed on ARM to produce a build failure when udelay

is called with a value > 2000.

Can you check the call to udelay that triggeres the reference to __bad_udelay?  It is likely larger than 2000.  I'm not sure, though, as to how a Clang change can trigger this.

--
You received this message because you are subscribed to the Google Groups "android-llvm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-llvm...@googlegroups.com.
To post to this group, send email to androi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nick Desaulniers]

On Wed, Apr 3, 2019 at 1:09 PM 'Pirama Arumuga Nainar' via
android-llvm <androi...@googlegroups.com> wrote:
>
> http://patchwork.ozlabs.org/patch/37903/:
>
> > According to the comment in arch/arm/include/asm/delay.h, __bad_udelay
> is specifically designed on ARM to produce a build failure when udelay
> is called with a value > 2000.

Specifically, a linkage failure, as observed below.

>
> Can you check the call to udelay that triggeres the reference to __bad_udelay? It is likely larger than 2000. I'm not sure, though, as to how a Clang change can trigger this.

Potentially related to __builtin_constant_p() changes in Clang, since
for arm32 mainline Linux kernel, I see:
https://elixir.bootlin.com/linux/latest/source/arch/arm/include/asm/delay.h#L67

It seems that udelay can otherwise be a macro defined in
include/asm-generic/delay.h that is also implemented in terms of
__builtin_constant_p().
https://elixir.bootlin.com/linux/latest/source/include/asm-generic/delay.h#L6

>
> On Tue, Apr 2, 2019 at 11:04 PM Michael <michaelben...@gmail.com> wrote:
>>
>> Oh also, this doesnt happened with clang 8 and below
>>
>> On Wednesday, April 3, 2019 at 5:03:22 PM UTC+11, Michael wrote:
>>>
>>> Hi,
>>>
>>> im compiling an exynos kernel with the latest clang toolchain found here https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/refs/heads/master with clang-r353983b (9.0.2 based on r353983b).
>>> I've tried to build my own clang tc and the problem still persists, kernel source can be found here http://opensource.samsung.com , search code SM-G950F G950FXXU4CRK1

Looks like the search code should just be `G950FXXU4CRK1`. I won't be
able to untar the kernel sources until Friday when I'm back from
travel.

>>>
>>> Error log captured after "LD init/built-in.o stage"
>>>
>>> drivers/built-in.o: In function `displayport_full_link_training':
>>> /home/vaughn/android/dream/drivers/video/fbdev/exynos/dpu/displayport_drv.c:403: undefined reference to `__bad_udelay'
>>>
>>> Someone mind helping me with this matter?

Is this file per chance not being compiled with optimizations turned
on? For example, this test case:
https://godbolt.org/z/p3senS

Produces references to __bad_udelay at -O0, but not -O1, -Os, -Oz, or
-O2, in the following Android prebuilts of Clang:
prebuilts/clang/host/linux-x86/clang-r349610/bin/clang
prebuilts/clang/host/linux-x86/clang-r349610b/bin/clang
prebuilts/clang/host/linux-x86/clang-r353983b/bin/clang

I suspect https://android-review.googlesource.com/c/toolchain/clang/+/938496
may help in this case. We'll be producing a r353983c build soon with
that fix cherry picked.

In the meantime, can you enable optimizations for that translation
unit if they're not already? In particular, it's really easy to mess
up/redefine KBUILD_CFLAGS in your subdir's Makefile, dropping -O2.
--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

On Wed, Apr 3, 2019 at 3:40 PM Nick Desaulniers <ndesau...@google.com> wrote:
> Looks like the search code should just be `G950FXXU4CRK1`. I won't be
> able to untar the kernel sources until Friday when I'm back from
> travel.

Nevermind, Crostini is pretty sweet.

>
> >>>
> >>> Error log captured after "LD init/built-in.o stage"
> >>>
> >>> drivers/built-in.o: In function `displayport_full_link_training':
> >>> /home/vaughn/android/dream/drivers/video/fbdev/exynos/dpu/displayport_drv.c:403: undefined reference to `__bad_udelay'

Looks like:

```c
static int displayport_full_link_training(void)
{
...
u8 training_aux_rd_interval;
...
training_aux_rd_interval = val[0];
...
udelay((training_aux_rd_interval*4000)+400);
...
```

I've modified my test case to match, and can still only repro at -O0
or not passing any optimization flag.

> >>>
> >>> Someone mind helping me with this matter?
>
> Is this file per chance not being compiled with optimizations turned
> on? For example, this test case:
> https://godbolt.org/z/p3senS
>
> Produces references to __bad_udelay at -O0, but not -O1, -Os, -Oz, or
> -O2, in the following Android prebuilts of Clang:
> prebuilts/clang/host/linux-x86/clang-r349610/bin/clang
> prebuilts/clang/host/linux-x86/clang-r349610b/bin/clang
> prebuilts/clang/host/linux-x86/clang-r353983b/bin/clang
>
> I suspect https://android-review.googlesource.com/c/toolchain/clang/+/938496
> may help in this case. We'll be producing a r353983c build soon with
> that fix cherry picked.
>
> In the meantime, can you enable optimizations for that translation
> unit if they're not already? In particular, it's really easy to mess
> up/redefine KBUILD_CFLAGS in your subdir's Makefile, dropping -O2.

Ok, so it looks like your device config
(arch/arm64/configs/exynos8895-dreamlte_defconfig) sets:
CONFIG_OPTIMIZE_FOR_SIZE=y
which in the top level Makefile sets -Oz. (Note that we recently
reverted this upstream https://lkml.org/lkml/2019/3/18/1110, I
*highly* recommend CONFIG_OPTIMIZE_FOR_PERFORMANCE=y unless you're
absolutely out of partition space, or have a better reason).

None of the intermediary Makefiles between the top level one and
drivers/video/fbdev/exynos/dpu/Makefile seen to mess with
KBUILD_CFLAGS.

As I'm remote, it's not easy for me to build this source. Can you
provide the output of:

$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu make CC=clang
drivers/video/fbdev/exynos/dpu/displayport_drv.o V=1

(particularly, I'm curious if any optimization flag is being passed).
--
Thanks,
~Nick Desaulniers

[Michael]

Hey, this is the output of it attached here https://del.dog/xowuhejevo.sql

[Nick Desaulniers]

On Wed, Apr 3, 2019 at 4:33 PM Michael <michaelben...@gmail.com> wrote:
>
> Hey, this is the output of it attached here https://del.dog/xowuhejevo.sql

Thanks, yeah I see `-Oz` being set. I'll have to play with my
reproducer more to see if I can reproduce a more minimal test case.
--
Thanks,
~Nick Desaulniers

[Michael]

that is with optimize for size being set =y.

also i dont know if this will help or not, i've tried backporting necessary patches to make LTO work on it, and the problem is gone when im using LTO. I know this problem just today when i decided to turn off LTO and remove the patches to do upstreams

[Nick Desaulniers]

On Wed, Apr 3, 2019 at 5:28 PM Michael <michaelben...@gmail.com> wrote:
>
> that is with optimize for size being set =y.

CONFIG_OPTIMIZE_FOR_SIZE=y and CONFIG_OPTIMIZE_FOR_PERFORMANCE=y are
mutually exclusive. If your kernel builds with
CONFIG_OPTIMIZE_FOR_PERFORMANCE=y, does that also reproduce the issue?
I'm curious if this will immediately unblock you, or if I should
start testing https://android-review.googlesource.com/c/toolchain/clang/+/938496.

> --
> You received this message because you are subscribed to the Google Groups "android-llvm" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-llvm...@googlegroups.com.
> To post to this group, send email to androi...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Thanks,
~Nick Desaulniers

[Michael]

Yes, it still have the issue.

and speaking of that the stock kernel doesnt have that CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE option so i need to switch to my own branch upstreamed with android-4.4 to test, and yes its still a problem.

On Wednesday, April 3, 2019 at 9:37:54 PM UTC+11, Nick Desaulniers wrote:

On Wed, Apr 3, 2019 at 5:28 PM Michael <michaelben...@gmail.com> wrote:
>
> that is with optimize for size being set =y.

CONFIG_OPTIMIZE_FOR_SIZE=y and CONFIG_OPTIMIZE_FOR_PERFORMANCE=y are
mutually exclusive.  If your kernel builds with
CONFIG_OPTIMIZE_FOR_PERFORMANCE=y, does that also reproduce the issue?
 I'm curious if this will immediately unblock you, or if I should
start testing https://android-review.googlesource.com/c/toolchain/clang/+/938496.

>
> also i dont know if this will help or not, i've tried backporting necessary patches to make LTO work on it, and the problem is gone when im using LTO. I know this problem just today when i decided to turn off LTO and remove the patches to do upstreams
>
> On Wednesday, April 3, 2019 at 9:20:18 PM UTC+11, Nick Desaulniers wrote:
>>
>> On Wed, Apr 3, 2019 at 4:33 PM Michael <michaelben...@gmail.com> wrote:
>> >
>> > Hey, this is the output of it attached here https://del.dog/xowuhejevo.sql
>>
>> Thanks, yeah I see `-Oz` being set.  I'll have to play with my
>> reproducer more to see if I can reproduce a more minimal test case.
>> --
>> Thanks,
>> ~Nick Desaulniers
>
> --
> You received this message because you are subscribed to the Google Groups "android-llvm" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to androi...@googlegroups.com.

[Nick Desaulniers]

Hi Michael, I'm back at the office now (traveled back to California
from Bangkok). Sorry for the delay. I'm now getting HTTP 404 from
http://opensource.samsung.com/ so I'm not able to re-fetch the
sources.

> To unsubscribe from this group and stop receiving emails from it, send an email to android-llvm...@googlegroups.com.

[Michael]

Hey, sorry for the late reply, you might want to revisit the website again, it's working just fine here.

[Michael]

Hey, if you're still not able to fetch it from the website, i would gladly upload it to gdrive and give the link to you.

[Nick Desaulniers]

Looks like I'm still having issues with our corp network. I've asked
our corp networking teams to investigate from our side. Sorry for the
delay; would you mind pushing the source to a different domain or
somewhere else I may be able to access it?

On Mon, Apr 8, 2019 at 4:02 AM Michael <michaelben...@gmail.com> wrote:
>
> Hey, if you're still not able to fetch it from the website, i would gladly upload it to gdrive and give the link to you.
>

> --
> You received this message because you are subscribed to the Google Groups "android-llvm" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to android-llvm...@googlegroups.com.

[Michael]

Hey, here's the link to the source (gdrive) https://drive.google.com/file/d/13ZuGynrgJm69VuK6rRybE9TYoUmVNZFe/view?usp=sharing .

Also there are couple of things you need to do before you are able to compile it successfully, here's a simple patch for it https://del.dog/fecogiruti.diff ,  and if you are building with an out folder , you need to made emulator8895_acpm_dvfs.fw and exynos8895_acpm_dvfs.fw to .fw.ihex using objcopy.

On Tuesday, April 9, 2019 at 6:24:35 AM UTC+10, Nick Desaulniers wrote:

Looks like I'm still having issues with our corp network.  I've asked
our corp networking teams to investigate from our side.  Sorry for the
delay; would you mind pushing the source to a different domain or
somewhere else I may be able to access it?

On Mon, Apr 8, 2019 at 4:02 AM Michael <michaelben...@gmail.com> wrote:
>
> Hey, if you're still not able to fetch it from the website, i would gladly upload it to gdrive and give the link to you.
>
> --
> You received this message because you are subscribed to the Google Groups "android-llvm" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to androi...@googlegroups.com.

[Michael]

Hey Nick, after further digging and testing. It seems like the problem starts happening right at "clang 8.0.8 (based on r349610) from build 5271481" and all of the next releases after it.

On Tuesday, April 9, 2019 at 6:24:35 AM UTC+10, Nick Desaulniers wrote:

Looks like I'm still having issues with our corp network.  I've asked
our corp networking teams to investigate from our side.  Sorry for the
delay; would you mind pushing the source to a different domain or
somewhere else I may be able to access it?

On Mon, Apr 8, 2019 at 4:02 AM Michael <michaelben...@gmail.com> wrote:
>
> Hey, if you're still not able to fetch it from the website, i would gladly upload it to gdrive and give the link to you.
>
> --
> You received this message because you are subscribed to the Google Groups "android-llvm" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to androi...@googlegroups.com.

[Nick Desaulniers]

On Tue, Apr 9, 2019 at 7:15 PM Michael <michaelben...@gmail.com> wrote:
>
> Hey Nick, after further digging and testing. It seems like the problem starts happening right at "clang 8.0.8 (based on r349610) from build 5271481" and all of the next releases after it.

Good to know. I hit quite a few compiler errors before I can get to
the issue you originally reported:
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang -j46
exynos8895-dreamlte_defconfig
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang -j46 &> log.txt

otherwise ToT clang works:
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang -j46
drivers/video/fbdev/exynos/dpu/displayport_drv.o
...
$ echo $?
0

And latest android llvm prebuilt:
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make
CC=/android1/android-master/prebuilts/clang/host/linux-x86/clang-r353983b/bin/clang
-j46 drivers/video/fbdev/exynos/dpu/displayport_drv.o
$ echo $?
0

Am I using the correct config?
--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

On Wed, Apr 10, 2019 at 4:01 PM Nick Desaulniers
<ndesau...@google.com> wrote:
>
> On Tue, Apr 9, 2019 at 7:15 PM Michael <michaelben...@gmail.com> wrote:
> >
> > Hey Nick, after further digging and testing. It seems like the problem starts happening right at "clang 8.0.8 (based on r349610) from build 5271481" and all of the next releases after it.
>
> Good to know. I hit quite a few compiler errors before I can get to
> the issue you originally reported:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang -j46
> exynos8895-dreamlte_defconfig
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang -j46 &> log.txt

attaching log.txt

>
> otherwise ToT clang works:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang -j46
> drivers/video/fbdev/exynos/dpu/displayport_drv.o
> ...
> $ echo $?
> 0
>
> And latest android llvm prebuilt:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make
> CC=/android1/android-master/prebuilts/clang/host/linux-x86/clang-r353983b/bin/clang
> -j46 drivers/video/fbdev/exynos/dpu/displayport_drv.o
> $ echo $?
> 0
>
> Am I using the correct config?
> --
> Thanks,
> ~Nick Desaulniers

--
Thanks,
~Nick Desaulniers

[Michael]

Hey, have you tried disabling -Werror in the Makefile

[Michael]

Seems like it, yes. i need to specify the clang directory to CC itself to compile it.

[Nick Desaulniers]

On Wed, Apr 10, 2019 at 5:24 PM Michael <michaelben...@gmail.com> wrote:
>
> Seems like it, yes. i need to specify the clang directory to CC itself to compile it.

That what this is doing:

>> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make
>> CC=/android1/android-master/prebuilts/clang/host/linux-x86/clang-r353983b/bin/clang
>> -j46 drivers/video/fbdev/exynos/dpu/displayport_drv.o
>> $ echo $?
>> 0

Still no errors.

> Hey, have you tried disabling -Werror in the Makefile

Yes, but I don't experience build warnings for the above translation
unit in the first place, so no errors.

Comparing the above command with V=1 against the linked log you
provided, it looks like your build additionally passes:

-DANDROID_VERSION=800000 -DANDROID_MAJOR_VERSION=8
-mno-unaligned-access -mstrict-align

Looks like ANDROID_VERSION only affects drivers/sensorhub,
drivers/net/wireless/bcmdhd4361, fs/ecryptfs/, and
fs/sdcardfs_v60000/.
ANDROID_MAJOR_VERSION is sensorhub again.
I don't suppose the two -m flags should make a difference.

Can you give me the *exact* commands you run to reproduce the issue,
starting from cloning that zip file you sent?
--
Thanks,
~Nick Desaulniers

[Michael]

Hey, this is the script i used for building it https://del.dog/xapomoviba.sh , you need to export BUILD_KERNEL_CLANG and BUILD_KERNEL_GCC.

and about the -m flags, it's mandatory for me to pass the flag while using clang so that i can boot the kernel (because without it, it wont boot).

Also, i export that android flag on my build script so that wifi and stuff would work properly.

[Michael]

Hi Nick, I've tried the newer clang-r353983c build but its still a no go

[Nick Desaulniers]

How are you setting BUILD_KERNEL_GCC in that script?

On Sun, Apr 21, 2019 at 6:56 AM Michael <michaelben...@gmail.com> wrote:
>
> Hi Nick, I've tried the newer clang-r353983c build but its still a no go
>

> --
> You received this message because you are subscribed to the Google Groups "android-llvm" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to android-llvm...@googlegroups.com.

[Michael]

Hey, sorry for the late reply, you need to define it with the gcc toolchain like this <tc directory>/bin/aarch64-linux-android-

On Tuesday, April 23, 2019 at 4:20:10 AM UTC+10, Nick Desaulniers wrote:

How are you setting BUILD_KERNEL_GCC in that script?

On Sun, Apr 21, 2019 at 6:56 AM Michael <michaelben...@gmail.com> wrote:
>
> Hi Nick, I've tried the newer clang-r353983c build but its still a no go
>
> --
> You received this message because you are subscribed to the Google Groups "android-llvm" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to androi...@googlegroups.com.