Linaro 4.9 toolchain has issues with allyesconfig

[Dan Murphy]

Hi!

When using the linaro-4.9-2015.05 toolchain on the Linux master and on Linux stable releases
I am seeing a build issue below when using the allyesconfig. This does not seem to occur on the 5.2 tool chain.
We cannot move to 5.2 tool chain for our releases as they are based on 4.9.

LD init/built-in.o
arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely'
drivers/built-in.o: In function `combiner_handle_cascade_irq':
:(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
drivers/built-in.o: In function `hip04_irq_set_type':
:(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
drivers/built-in.o: In function `hip04_raise_softirq':
:(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock_irqsave' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o
drivers/built-in.o: In function `hip04_irq_set_affinity':
:(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xf78): additional relocation overflows omitted from the output
make: *** [vmlinux] Error 1

Please advise to how to resolve this issue within the 4.9 Linaro tool chain

Dan

[Christophe Lyon]

Post by Dan Murphy
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on Linux stable releases
I am seeing a build issue below when using the allyesconfig. This does not seem to occur on the 5.2 tool chain.
We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o
arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely'
:(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock_irqsave' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xf78): additional relocation overflows omitted from the output
make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain

Hi Dan,

It would be better to report this kind of problem using our bugzilla:
https://bugs.linaro.org/

I've managed to reproduce it, except for the errors with R__ARM_JUMP24.
Maybe that's because I used linux-4.3.3.tar.xz.

Anyway, these errors indicate branches trying reach a function which
is too far away from the call site.
Normally, the linker inserts stubs (trampolines) to handle such
situations, but here the .text section
of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case.
The linker is able to insert trampolines at section boundaries
(between object files), but in this case
it cannot insert one close enough, hence the error you are seeing.

The range of branch instructions is indicated for instance here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfddaf.html

I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.

Christophe.

Post by Dan Murphy
Dan
--
------------------
Dan Murphy
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Dan Murphy]

Christophe

Post by Christophe Lyon

Post by Dan Murphy
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on Linux stable releases
I am seeing a build issue below when using the allyesconfig. This does not seem to occur on the 5.2 tool chain.
We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o
arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely'
:(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock_irqsave' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xf78): additional relocation overflows omitted from the output
make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain

Hi Dan,
https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24.
Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which
is too far away from the call site.
Normally, the linker inserts stubs (trampolines) to handle such
situations, but here the .text section
of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case.
The linker is able to insert trampolines at section boundaries
(between object files), but in this case
it cannot insert one close enough, hence the error you are seeing.

Do we know if this is a linux kernel issue or a linker issue that got
exposed
when a patch came in?

Dan

Post by Christophe Lyon
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfddaf.html
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.

Post by Dan Murphy
Dan
--
------------------
Dan Murphy
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Christophe Lyon]

Post by Christophe Lyon
Christophe

Post by Christophe Lyon

Post by Dan Murphy
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on
Linux stable releases
I am seeing a build issue below when using the allyesconfig. This does
not seem to occur on the 5.2 tool chain.
We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o
arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
:(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock_irqsave' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock_irqrestore' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xf78): additional relocation overflows omitted from the output
make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain

Hi Dan,
https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24.
Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which
is too far away from the call site.
Normally, the linker inserts stubs (trampolines) to handle such
situations, but here the .text section
of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case.
The linker is able to insert trampolines at section boundaries
(between object files), but in this case
it cannot insert one close enough, hence the error you are seeing.

Do we know if this is a linux kernel issue or a linker issue that got
exposed
when a patch came in?

I don't know, but I'm not a kernel expert.

It's likely that the allyes config produces large object files.

Did it ever work for you?

With a known-to-work starting point we could try to bisect
and identify went the problem appeared.

Christophe.

Post by Christophe Lyon
Dan

Post by Christophe Lyon
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfddaf.html
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.

Post by Dan Murphy
Dan
--
------------------
Dan Murphy
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

--
----------------------------------------------
Dan Murphy

[Christophe Lyon]

Post by Christophe Lyon

Post by Christophe Lyon
Christophe

Post by Christophe Lyon

Post by Dan Murphy
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on
Linux stable releases
I am seeing a build issue below when using the allyesconfig. This does
not seem to occur on the 5.2 tool chain.
We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o
arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
:(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock_irqsave' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock_irqrestore' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xf78): additional relocation overflows omitted from the output
make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain

Hi Dan,
https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24.
Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which
is too far away from the call site.
Normally, the linker inserts stubs (trampolines) to handle such
situations, but here the .text section
of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case.
The linker is able to insert trampolines at section boundaries
(between object files), but in this case
it cannot insert one close enough, hence the error you are seeing.

Do we know if this is a linux kernel issue or a linker issue that got
exposed
when a patch came in?

I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?
With a known-to-work starting point we could try to bisect
and identify went the problem appeared.

FWIW, I've just reproduced the same build error with
gcc-linaro-5.2-2015.11-1, as expected.

Christophe.

Post by Christophe Lyon
Christophe.

Post by Christophe Lyon
Dan

Post by Christophe Lyon
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfddaf.html
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.

Post by Dan Murphy
Dan
--
------------------
Dan Murphy
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

--
----------------------------------------------
Dan Murphy

[Richard Earnshaw]

Post by Christophe Lyon

Post by Christophe Lyon
Christophe

Post by Christophe Lyon

Post by Dan Murphy
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on
Linux stable releases
I am seeing a build issue below when using the allyesconfig. This does
not seem to occur on the 5.2 tool chain.
We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o
arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
:(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock_irqsave' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock_irqrestore' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xf78): additional relocation overflows omitted from the output
make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain

Hi Dan,
https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24.
Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which
is too far away from the call site.
Normally, the linker inserts stubs (trampolines) to handle such
situations, but here the .text section
of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case.
The linker is able to insert trampolines at section boundaries
(between object files), but in this case
it cannot insert one close enough, hence the error you are seeing.

Do we know if this is a linux kernel issue or a linker issue that got
exposed
when a patch came in?

I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?
With a known-to-work starting point we could try to bisect
and identify went the problem appeared.

I find it hard to believe that a compiler could generate a single object
file that contained 84Mb of code, it would take an inordinate amount of
code to do that even if optimizations were turned off. So that leaves
two likely options:

1) The file is constructed by concatenating multiple object files,
perhaps with ld -r to produce a partially linked object file.
2) The file contains some directives that are inserting large amounts of
padding.

Either way, I suspect that this is going to require fixing in the Linux
build system. You've hit a fundamental limit of the AArch32
architecture, as Christophe has mentioned and there's nothing at this
point that the tools can do to help you.

R.

Post by Christophe Lyon
Christophe.

Post by Christophe Lyon
Dan

Post by Christophe Lyon
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfddaf.html
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.

Post by Dan Murphy
Dan
--
------------------
Dan Murphy
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

--
----------------------------------------------
Dan Murphy

_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[William Mills]

Post by Richard Earnshaw

Post by Christophe Lyon

Post by Christophe Lyon
Christophe

Post by Christophe Lyon

Post by Dan Murphy
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on
Linux stable releases
I am seeing a build issue below when using the allyesconfig. This does
not seem to occur on the 5.2 tool chain.
We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o
arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
:(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock_irqsave' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock_irqrestore' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xf78): additional relocation overflows omitted from the output
make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain

Hi Dan,
https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24.
Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which
is too far away from the call site.
Normally, the linker inserts stubs (trampolines) to handle such
situations, but here the .text section
of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case.
The linker is able to insert trampolines at section boundaries
(between object files), but in this case
it cannot insert one close enough, hence the error you are seeing.

Do we know if this is a linux kernel issue or a linker issue that got
exposed
when a patch came in?

I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?

Still a valid question

Post by Richard Earnshaw

Post by Christophe Lyon
With a known-to-work starting point we could try to bisect
and identify went the problem appeared.

I find it hard to believe that a compiler could generate a single object
file that contained 84Mb of code, it would take an inordinate amount of
code to do that even if optimizations were turned off. So that leaves
1) The file is constructed by concatenating multiple object files,
perhaps with ld -r to produce a partially linked object file.

Which the kernel build does for each sub-directory (recursively)
This is the case of drivers/built-in.o
This is not new, the kernel has been using this technique for years.

Does the trampoline generation not happen for ld -r ?

Post by Richard Earnshaw
2) The file contains some directives that are inserting large amounts of
padding.

- or -
3) using incbin to include a binary file into the object file
This is used when building a compressed kernel and other places.

Post by Richard Earnshaw
Either way, I suspect that this is going to require fixing in the Linux
build system. You've hit a fundamental limit of the AArch32
architecture, as Christophe has mentioned and there's nothing at this
point that the tools can do to help you.
R.

Post by Christophe Lyon
Christophe.

Post by Christophe Lyon
Dan

Post by Christophe Lyon
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfddaf.html
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.

Post by Dan Murphy
Dan
--
------------------
Dan Murphy
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

--
----------------------------------------------
Dan Murphy

_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Richard Earnshaw]

Post by William Mills

Post by Richard Earnshaw

Post by Christophe Lyon

Post by Christophe Lyon
Christophe

Post by Christophe Lyon

Post by Dan Murphy
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on
Linux stable releases
I am seeing a build issue below when using the allyesconfig. This does
not seem to occur on the 5.2 tool chain.
We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o
arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
:(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock_irqsave' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock_irqrestore' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xf78): additional relocation overflows omitted from the output
make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain

Hi Dan,
https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24.
Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which
is too far away from the call site.
Normally, the linker inserts stubs (trampolines) to handle such
situations, but here the .text section
of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case.
The linker is able to insert trampolines at section boundaries
(between object files), but in this case
it cannot insert one close enough, hence the error you are seeing.

Do we know if this is a linux kernel issue or a linker issue that got
exposed
when a patch came in?

I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?

Still a valid question

Post by Richard Earnshaw

Post by Christophe Lyon
With a known-to-work starting point we could try to bisect
and identify went the problem appeared.

I find it hard to believe that a compiler could generate a single object
file that contained 84Mb of code, it would take an inordinate amount of
code to do that even if optimizations were turned off. So that leaves
1) The file is constructed by concatenating multiple object files,
perhaps with ld -r to produce a partially linked object file.

Which the kernel build does for each sub-directory (recursively)
This is the case of drivers/built-in.o
This is not new, the kernel has been using this technique for years.
Does the trampoline generation not happen for ld -r ?

I don't believe so. It would be hard to do it then anyway because the
type of trampoline (and whether a trampoline is even permitted) depends
on the the symbol that the code resolves to and that probably isn't
known during the pre-linking step.

R.

Post by William Mills

Post by Richard Earnshaw
2) The file contains some directives that are inserting large amounts of
padding.

- or -
3) using incbin to include a binary file into the object file
This is used when building a compressed kernel and other places.

Post by Richard Earnshaw
Either way, I suspect that this is going to require fixing in the Linux
build system. You've hit a fundamental limit of the AArch32
architecture, as Christophe has mentioned and there's nothing at this
point that the tools can do to help you.
R.

Post by Christophe Lyon
Christophe.

Post by Christophe Lyon
Dan

Post by Christophe Lyon
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfddaf.html
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.

Post by Dan Murphy
Dan
--
------------------
Dan Murphy
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

--
----------------------------------------------
Dan Murphy

_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Christophe Lyon]

Post by Richard Earnshaw

Post by William Mills

Post by Richard Earnshaw

Post by Christophe Lyon

Post by Christophe Lyon
Christophe

Post by Christophe Lyon

Post by Dan Murphy
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on
Linux stable releases
I am seeing a build issue below when using the allyesconfig. This does
not seem to occur on the 5.2 tool chain.
We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o
arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
:(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock_irqsave' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock_irqrestore' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xf78): additional relocation overflows omitted from the output
make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain

Hi Dan,
https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24.
Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which
is too far away from the call site.
Normally, the linker inserts stubs (trampolines) to handle such
situations, but here the .text section
of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case.
The linker is able to insert trampolines at section boundaries
(between object files), but in this case
it cannot insert one close enough, hence the error you are seeing.

Do we know if this is a linux kernel issue or a linker issue that got
exposed
when a patch came in?

I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?

Still a valid question

Post by Richard Earnshaw

Post by Christophe Lyon
With a known-to-work starting point we could try to bisect
and identify went the problem appeared.

I find it hard to believe that a compiler could generate a single object
file that contained 84Mb of code, it would take an inordinate amount of
code to do that even if optimizations were turned off. So that leaves
1) The file is constructed by concatenating multiple object files,
perhaps with ld -r to produce a partially linked object file.

Which the kernel build does for each sub-directory (recursively)
This is the case of drivers/built-in.o
This is not new, the kernel has been using this technique for years.
Does the trampoline generation not happen for ld -r ?

I don't believe so. It would be hard to do it then anyway because the
type of trampoline (and whether a trampoline is even permitted) depends
on the the symbol that the code resolves to and that probably isn't
known during the pre-linking step.

I confirm the trampolines are not inserted for ld -r.

Maybe using -ffunction-sections would help?

Christophe.

Post by Richard Earnshaw
R.

Post by William Mills

Post by Richard Earnshaw
2) The file contains some directives that are inserting large amounts of
padding.

- or -
3) using incbin to include a binary file into the object file
This is used when building a compressed kernel and other places.

Post by Richard Earnshaw
Either way, I suspect that this is going to require fixing in the Linux
build system. You've hit a fundamental limit of the AArch32
architecture, as Christophe has mentioned and there's nothing at this
point that the tools can do to help you.
R.

Post by Christophe Lyon
Christophe.

Post by Christophe Lyon
Dan

Post by Christophe Lyon
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfddaf.html
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.

Post by Dan Murphy
Dan
--
------------------
Dan Murphy
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

--
----------------------------------------------
Dan Murphy

_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Jim Wilson]

On Wed, Jan 27, 2016 at 8:37 AM, Christophe Lyon

Post by Christophe Lyon
I confirm the trampolines are not inserted for ld -r.

We can't insert the trampolines with ld -r. We don't have all of the
symbols required for this with a relocatable link. Also, for the
symbols we do have, we don't know the final addresses, so we don't
know which branches/calls will be out of range.

Post by Christophe Lyon
Maybe using -ffunction-sections would help?

Using -mlong-calls might be easier. You would only want this enabled
for a allyesconfig build of course. This should solve the
out-of-range calls to the spin lock functions. it probably doesn't
help for the out-of-range branches to the .text.unlikely sections, but
this is a gcc optimization that can be disabled with
-fno-reorder-functions. This is again something you would only want
for an allyesconfig build.

Jim

[Richard Earnshaw]

Post by Jim Wilson
On Wed, Jan 27, 2016 at 8:37 AM, Christophe Lyon

Post by Christophe Lyon
I confirm the trampolines are not inserted for ld -r.

We can't insert the trampolines with ld -r. We don't have all of the
symbols required for this with a relocatable link. Also, for the
symbols we do have, we don't know the final addresses, so we don't
know which branches/calls will be out of range.

Post by Christophe Lyon
Maybe using -ffunction-sections would help?

Using -mlong-calls might be easier. You would only want this enabled
for a allyesconfig build of course. This should solve the
out-of-range calls to the spin lock functions. it probably doesn't
help for the out-of-range branches to the .text.unlikely sections, but
this is a gcc optimization that can be disabled with
-fno-reorder-functions. This is again something you would only want
for an allyesconfig build.
Jim

Long calls would probably solve the problem, but would likely be
horribly expensive in performance.

The best solution would be to have an option to prevent ld -r from
merging like-named sections (instead just aggregating multiple sections
with similar names into one object file). This is possible in ELF.

R.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Jim Wilson]

On Wed, Jan 27, 2016 at 9:30 AM, Richard Earnshaw

Post by Richard Earnshaw
Long calls would probably solve the problem, but would likely be
horribly expensive in performance.

An allyesconfig is presumably only to verify that you haven't
accidentally broken any build config with a patch, so performance
should not be a concern.

Post by Richard Earnshaw
The best solution would be to have an option to prevent ld -r from
merging like-named sections (instead just aggregating multiple sections
with similar names into one object file). This is possible in ELF.

Another way to do this is to make an archive file instead of using ld
-r, and then use --whole-archive <archivefile> --no-whole-archive.
That would avoid the need for linker changes.

While it might be possible to make an ELF file with multiple sections
with the same name, that would likely confuse lots of tools, and
require cascading changes, which could get ugly.

Jim

[Christophe Lyon]

Post by Jim Wilson
On Wed, Jan 27, 2016 at 9:30 AM, Richard Earnshaw

Post by Richard Earnshaw
Long calls would probably solve the problem, but would likely be
horribly expensive in performance.

An allyesconfig is presumably only to verify that you haven't
accidentally broken any build config with a patch, so performance
should not be a concern.

Post by Richard Earnshaw
The best solution would be to have an option to prevent ld -r from
merging like-named sections (instead just aggregating multiple sections
with similar names into one object file). This is possible in ELF.

Another way to do this is to make an archive file instead of using ld
-r, and then use --whole-archive <archivefile> --no-whole-archive.
That would avoid the need for linker changes.
While it might be possible to make an ELF file with multiple sections
with the same name, that would likely confuse lots of tools, and
require cascading changes, which could get ugly.
Jim

I've just tried with-ffunction-sections, but I got:
drivers/built-in.o:(.text.fixup+0x264): relocation truncated to fit:
R_ARM_JUMP24 against `.text.armada_gem_pwrite_ioctl'
drivers/built-in.o:(.text.fixup+0x270): relocation truncated to fit:
R_ARM_JUMP24 against `.text.armada_gem_pwrite_ioctl'
drivers/built-in.o:(.text.fixup+0x278): relocation truncated to fit:
R_ARM_JUMP24 against `.text.scsi_ioctl'
drivers/built-in.o:(.text.fixup+0x280): relocation truncated to fit:
R_ARM_JUMP24 against `.text.scsi_ioctl'
drivers/built-in.o:(.text.fixup+0x288): relocation truncated to fit:
R_ARM_JUMP24 against `.text.sg_ioctl'
drivers/built-in.o:(.text.fixup+0x290): relocation truncated to fit:
R_ARM_JUMP24 against `.text.sg_ioctl'
drivers/built-in.o:(.text.fixup+0x298): relocation truncated to fit:
R_ARM_JUMP24 against `.text.sg_ioctl'
drivers/built-in.o:(.text.fixup+0x2a0): relocation truncated to fit:
R_ARM_JUMP24 against `.text.sg_ioctl'
drivers/built-in.o:(.text.fixup+0x2a8): relocation truncated to fit:
R_ARM_JUMP24 against `.text.sg_ioctl'
drivers/built-in.o:(.text.fixup+0x2b0): relocation truncated to fit:
R_ARM_JUMP24 against `.text.sg_ioctl'
drivers/built-in.o:(.text.fixup+0x2b8): additional relocation
overflows omitted from the output

Now, with -mlong-calls, I got:
drivers/built-in.o: In function `atom_op_mul':
sunxi_sid.c:(.text+0xa2c334): relocation truncated to fit: R_ARM_CALL
against symbol `__gnu_mcount_nc' defined in .text section in
arch/arm/kernel/built-in.o
drivers/built-in.o: In function `atom_op_move':
sunxi_sid.c:(.text+0xa2c4d4): relocation truncated to fit: R_ARM_CALL
against symbol `__gnu_mcount_nc' defined in .text section in
arch/arm/kernel/built-in.o
drivers/built-in.o: In function `atom_op_mask':
sunxi_sid.c:(.text+0xa2c830): relocation truncated to fit: R_ARM_CALL
against symbol `__gnu_mcount_nc' defined in .text section in
arch/arm/kernel/built-in.o
drivers/built-in.o: In function `atom_op_div':
sunxi_sid.c:(.text+0xa2cb1c): relocation truncated to fit: R_ARM_CALL
against symbol `__gnu_mcount_nc' defined in .text section in
arch/arm/kernel/built-in.o
drivers/built-in.o: In function `atom_op_compare':
sunxi_sid.c:(.text+0xa2cd10): relocation truncated to fit: R_ARM_CALL
against symbol `__gnu_mcount_nc' defined in .text section in
arch/arm/kernel/built-in.o
drivers/built-in.o: In function `atom_op_and':
sunxi_sid.c:(.text+0xa2cfa0): relocation truncated to fit: R_ARM_CALL
against symbol `__gnu_mcount_nc' defined in .text section in
arch/arm/kernel/built-in.o
drivers/built-in.o: In function `atom_op_add':
sunxi_sid.c:(.text+0xa2d1e0): relocation truncated to fit: R_ARM_CALL
against symbol `__gnu_mcount_nc' defined in .text section in
arch/arm/kernel/built-in.o
drivers/built-in.o: In function `atom_op_delay':
sunxi_sid.c:(.text+0xa2d41c): relocation truncated to fit: R_ARM_CALL
against symbol `__gnu_mcount_nc' defined in .text section in
arch/arm/kernel/built-in.o
drivers/built-in.o: In function `atom_op_jump':
sunxi_sid.c:(.text+0xa2d624): relocation truncated to fit: R_ARM_CALL
against symbol `__gnu_mcount_nc' defined in .text section in
arch/arm/kernel/built-in.o
drivers/built-in.o: In function `amdgpu_atom_execute_table_locked':
sunxi_sid.c:(.text+0xa2da2c): relocation truncated to fit: R_ARM_CALL
against symbol `__gnu_mcount_nc' defined in .text section in
arch/arm/kernel/built-in.o

Which is surprising. But maybe I didn't add -mlong-calls where I
should have and some files were compiled without it, or there are asm
fragments using direct calls?

So... it looks like there is no straight forward route.

Christophe.

[Jim Wilson]

On Thu, Jan 28, 2016 at 7:15 AM, Christophe Lyon

Post by Christophe Lyon
sunxi_sid.c:(.text+0xa2c334): relocation truncated to fit: R_ARM_CALL
against symbol `__gnu_mcount_nc' defined in .text section in
arch/arm/kernel/built-in.o

This is a minor arm port bug. Use both -mlong-calls and -pg and you get
bl __gnu_mcount_nc
instead of the long call to mcount that I expected. The MIPS port
does get this right, and uses a longcall for mcount if longcalls are
enabled.

But you got me thinking about this. There is a bit of assembly code
in the kernel, and you might run into other similar issues that would
require kernel changes to make this work, so this isn't a trivial
solution, but I think it is still doable if someone cared enough.

I also noticed that the kernel has support for dynamically modifying
code to enable/disable the profiling calls. That would need changing
to support long calls if you want this kernel to work. But if an
allyesconfig is only to verify that the kernel builds, this may not
matter.

Jim

[Renato Golin]

Post by Jim Wilson
This is a minor arm port bug. Use both -mlong-calls and -pg and you get
bl __gnu_mcount_nc
instead of the long call to mcount that I expected. The MIPS port
does get this right, and uses a longcall for mcount if longcalls are
enabled.

Hi Jim,

We have this bug in LLVM:

https://llvm.org/bugs/show_bug.cgi?id=23969

Which deals with the problems of mcount messing up the prologue, and
it seems to affect both kernel and chromium.

I was delaying the decision to move to __gnu_mcount_nc on ARM
unconditionally, but if GCC requires the -mlong-calls option, then I
think we could make it work very easily.

Is this in line of what you were suggesting, or am I crossing the wires here?

cheers,
--renato

[Jim Wilson]

Post by Renato Golin
https://llvm.org/bugs/show_bug.cgi?id=23969
Which deals with the problems of mcount messing up the prologue, and
it seems to affect both kernel and chromium.

This is an unrelated problem.

Post by Renato Golin
I was delaying the decision to move to __gnu_mcount_nc on ARM
unconditionally, but if GCC requires the -mlong-calls option, then I
think we could make it work very easily.

GCC does not require -mlong-calls.

This is a specific problem related to the kernel allyesconfig option
which enables everything, resulting in a kernel so large, with ld -r
combined text sections so large, that we get out-of-range calls that
linker relaxation can't fix. I was suggesting -mlong-calls as a
workaround, except that it turns out that -mlong-calls -pg doesn't
work, because we always emit a short-call to mcount, even when
-mlong-calls is specified. That is a minor bug in the gcc ARM port.

Jim

[Dan Murphy]

Post by William Mills

Post by Richard Earnshaw

Post by Christophe Lyon

Post by Christophe Lyon
Christophe

Post by Christophe Lyon

Post by Dan Murphy
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on
Linux stable releases
I am seeing a build issue below when using the allyesconfig. This does
not seem to occur on the 5.2 tool chain.
We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o
arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to
fit: R_ARM_JUMP24 against `.text.unlikely'
:(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock_irqsave' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_unlock_irqrestore' defined in .spinlock.text section in
kernel/built-in.o
:(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol
`_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o
:(.text+0xf78): additional relocation overflows omitted from the output
make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain

Hi Dan,
https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24.
Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which
is too far away from the call site.
Normally, the linker inserts stubs (trampolines) to handle such
situations, but here the .text section
of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case.
The linker is able to insert trampolines at section boundaries
(between object files), but in this case
it cannot insert one close enough, hence the error you are seeing.

Do we know if this is a linux kernel issue or a linker issue that got
exposed
when a patch came in?

I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?

Still a valid question

I went back to v4.1 tag from Linus and the build still fails for allyes.

I tried to reproduce my 5.2 results with the arm-none toolchain but the
kernel does not even compile with that compiler. Not sure if the Linux kernel is supposed
to compile with arm-none toolchain.



Dan

Post by William Mills

Post by Richard Earnshaw

Post by Christophe Lyon
With a known-to-work starting point we could try to bisect
and identify went the problem appeared.

I find it hard to believe that a compiler could generate a single object
file that contained 84Mb of code, it would take an inordinate amount of
code to do that even if optimizations were turned off. So that leaves
1) The file is constructed by concatenating multiple object files,
perhaps with ld -r to produce a partially linked object file.

Which the kernel build does for each sub-directory (recursively)
This is the case of drivers/built-in.o
This is not new, the kernel has been using this technique for years.
Does the trampoline generation not happen for ld -r ?

Post by Richard Earnshaw
2) The file contains some directives that are inserting large amounts of
padding.

- or -
3) using incbin to include a binary file into the object file
This is used when building a compressed kernel and other places.

Post by Richard Earnshaw
Either way, I suspect that this is going to require fixing in the Linux
build system. You've hit a fundamental limit of the AArch32
architecture, as Christophe has mentioned and there's nothing at this
point that the tools can do to help you.
R.

Post by Christophe Lyon
Christophe.

Post by Christophe Lyon
Dan

Post by Christophe Lyon
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfddaf.html
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.

Post by Dan Murphy
Dan
--
------------------
Dan Murphy
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

--
----------------------------------------------
Dan Murphy

_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain