l1_text is at L1_CODE_START (e.g. for bf533, 0xff800000). If the kernel
is too big, it may be overwritten, the related issue:
LD init/built-in.o
init/built-in.o: In function `do_early_param':
init/main.c:(.init.text+0xe0): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
init/main.c:(.init.text+0x10e): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
init/built-in.o: In function `unknown_bootoption':
blackfin is for embedded system, the size limitition is acceptable, so
it is not the real world issue, which should be skipped if COMPILE_TEST
enabled.
Signed-off-by: Chen Gang <[email protected]>
---
arch/blackfin/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/blackfin/Makefile b/arch/blackfin/Makefile
index 2ece4e3..e5195b4 100644
--- a/arch/blackfin/Makefile
+++ b/arch/blackfin/Makefile
@@ -20,6 +20,9 @@ endif
KBUILD_AFLAGS += $(call cc-option,-mno-fdpic)
KBUILD_CFLAGS_MODULE += -mlong-calls
LDFLAGS += -m elf32bfin
+ifeq ($(CONFIG_COMPILE_TEST),y)
+LDFLAGS += --noinhibit-exec
+endif
KBUILD_DEFCONFIG := BF537-STAMP_defconfig
--
1.9.3
After this patch, blackfin can pass allmodconfig building (if we treat
it as allmodconfig). And next, I shall try to:
- Send all related patches v2 for blackfin kernel within this month.
- Fix blackfin gcc/binutils related issues within this month.
Thanks.
On 4/9/15 05:03, Chen Gang wrote:
> l1_text is at L1_CODE_START (e.g. for bf533, 0xff800000). If the kernel
> is too big, it may be overwritten, the related issue:
>
> LD init/built-in.o
> init/built-in.o: In function `do_early_param':
> init/main.c:(.init.text+0xe0): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
> init/main.c:(.init.text+0x10e): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
> init/built-in.o: In function `unknown_bootoption':
>
> blackfin is for embedded system, the size limitition is acceptable, so
> it is not the real world issue, which should be skipped if COMPILE_TEST
> enabled.
>
>
> Signed-off-by: Chen Gang <[email protected]>
> ---
> arch/blackfin/Makefile | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/blackfin/Makefile b/arch/blackfin/Makefile
> index 2ece4e3..e5195b4 100644
> --- a/arch/blackfin/Makefile
> +++ b/arch/blackfin/Makefile
> @@ -20,6 +20,9 @@ endif
> KBUILD_AFLAGS += $(call cc-option,-mno-fdpic)
> KBUILD_CFLAGS_MODULE += -mlong-calls
> LDFLAGS += -m elf32bfin
> +ifeq ($(CONFIG_COMPILE_TEST),y)
> +LDFLAGS += --noinhibit-exec
> +endif
>
> KBUILD_DEFCONFIG := BF537-STAMP_defconfig
>
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Am 08.04.2015 um 23:10 schrieb Chen Gang:
>
> After this patch, blackfin can pass allmodconfig building (if we treat
> it as allmodconfig). And next, I shall try to:
>
> - Send all related patches v2 for blackfin kernel within this month.
>
> - Fix blackfin gcc/binutils related issues within this month.
All you do is randomly papering over issues to make the allmodconfig build
somehow proceed.
This is not the correct way to deal with problems.
Thanks,
//richard
On 4/9/15 05:12, Richard Weinberger wrote:
> Am 08.04.2015 um 23:10 schrieb Chen Gang:
>>
>> After this patch, blackfin can pass allmodconfig building (if we treat
>> it as allmodconfig). And next, I shall try to:
>>
>> - Send all related patches v2 for blackfin kernel within this month.
>>
>> - Fix blackfin gcc/binutils related issues within this month.
>
> All you do is randomly papering over issues to make the allmodconfig build
> somehow proceed.
> This is not the correct way to deal with problems.
>
Still, for me, it is not a good idea to make a conclusion in discussing.
For gcc/binutils issues, they are real world issue, they need to be
fixed, next (I shall try to fix them within this month).
Some of my blackfin kernel patches need send v2, I shall send them
next. And others are discussing now. If you do not agree with one of
them, please continue discussing in the related thread.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Am 09.04.2015 um 15:28 schrieb Chen Gang:
> On 4/9/15 05:12, Richard Weinberger wrote:
>> Am 08.04.2015 um 23:10 schrieb Chen Gang:
>>>
>>> After this patch, blackfin can pass allmodconfig building (if we treat
>>> it as allmodconfig). And next, I shall try to:
>>>
>>> - Send all related patches v2 for blackfin kernel within this month.
>>>
>>> - Fix blackfin gcc/binutils related issues within this month.
>>
>> All you do is randomly papering over issues to make the allmodconfig build
>> somehow proceed.
>> This is not the correct way to deal with problems.
>>
>
> Still, for me, it is not a good idea to make a conclusion in discussing.
>
> For gcc/binutils issues, they are real world issue, they need to be
> fixed, next (I shall try to fix them within this month).
I leave that up to the blackfin maintainer.
IMHO this is wrong, you're not fixing a real world issue, all you do is
making allmodconfig somehow proceed by papering over possible real issues
which you cannot test as you don't have blackfin hardware.
Thanks,
//richard
On 4/9/15 21:38, Richard Weinberger wrote:
> Am 09.04.2015 um 15:28 schrieb Chen Gang:
>> On 4/9/15 05:12, Richard Weinberger wrote:
>>> Am 08.04.2015 um 23:10 schrieb Chen Gang:
>>>>
>>>> After this patch, blackfin can pass allmodconfig building (if we treat
>>>> it as allmodconfig). And next, I shall try to:
>>>>
>>>> - Send all related patches v2 for blackfin kernel within this month.
>>>>
>>>> - Fix blackfin gcc/binutils related issues within this month.
>>>
>>> All you do is randomly papering over issues to make the allmodconfig build
>>> somehow proceed.
>>> This is not the correct way to deal with problems.
>>>
>>
>> Still, for me, it is not a good idea to make a conclusion in discussing.
>>
>> For gcc/binutils issues, they are real world issue, they need to be
>> fixed, next (I shall try to fix them within this month).
>
> I leave that up to the blackfin maintainer.
OK, thanks.
> IMHO this is wrong, you're not fixing a real world issue, all you do is
> making allmodconfig somehow proceed by papering over possible real issues
> which you cannot test as you don't have blackfin hardware.
>
For me, it is not a real world issue, the user should not let it happen.
It is only about building test (COMPILE_TEST).
And for me, the root cause is:
- init section is the last section which can be dropped easily.
- but init section includes l1 section (which may also include sched
section).
- l1 section has fixed address. If the kernel is too big, l1 section
will be overwrite, so ld report "reloc overflow".
Welcome any other ideas, discussions or completions.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Hi,
On Thu, Apr 9, 2015 at 5:03 AM, Chen Gang <[email protected]> wrote:
> l1_text is at L1_CODE_START (e.g. for bf533, 0xff800000). If the kernel
> is too big, it may be overwritten, the related issue:
>
> LD init/built-in.o
> init/built-in.o: In function `do_early_param':
> init/main.c:(.init.text+0xe0): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
> init/main.c:(.init.text+0x10e): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
blackfin toolchain generate 24 bit pc-relative calls by default, with
a range of –16,777,216 through 16,777,214 (0xFF00 0000 to 0x00FF FFFE)
is available.
So call to l1_text should be ok. What do you mean the kernel is too big?
http://docs.blackfin.uclinux.org/doku.php?id=ism:call
> init/built-in.o: In function `unknown_bootoption':
>
> blackfin is for embedded system, the size limitition is acceptable, so
> it is not the real world issue, which should be skipped if COMPILE_TEST
> enabled.
>
>
> Signed-off-by: Chen Gang <[email protected]>
> ---
> arch/blackfin/Makefile | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/blackfin/Makefile b/arch/blackfin/Makefile
> index 2ece4e3..e5195b4 100644
> --- a/arch/blackfin/Makefile
> +++ b/arch/blackfin/Makefile
> @@ -20,6 +20,9 @@ endif
> KBUILD_AFLAGS += $(call cc-option,-mno-fdpic)
> KBUILD_CFLAGS_MODULE += -mlong-calls
> LDFLAGS += -m elf32bfin
> +ifeq ($(CONFIG_COMPILE_TEST),y)
> +LDFLAGS += --noinhibit-exec
> +endif
>
> KBUILD_DEFCONFIG := BF537-STAMP_defconfig
>
> --
> 1.9.3
On 4/22/15 17:00, Steven Miao wrote:
> Hi,
>
> On Thu, Apr 9, 2015 at 5:03 AM, Chen Gang <[email protected]> wrote:
>> l1_text is at L1_CODE_START (e.g. for bf533, 0xff800000). If the kernel
>> is too big, it may be overwritten, the related issue:
>>
>> LD init/built-in.o
>> init/built-in.o: In function `do_early_param':
>> init/main.c:(.init.text+0xe0): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
>> init/main.c:(.init.text+0x10e): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
> blackfin toolchain generate 24 bit pc-relative calls by default, with
> a range of –16,777,216 through 16,777,214 (0xFF00 0000 to 0x00FF FFFE)
> is available.
> So call to l1_text should be ok. What do you mean the kernel is too big?
> http://docs.blackfin.uclinux.org/doku.php?id=ism:call
>
>
Excuse me, I am not quite familiar with what you said above, can we
also treat 24-bit as 16MB size limitation for kernel size? I am not
quite sure, could you provide more information about it?.
And I checked "arch/blackfin/kernel/vmlinux.lds.S", for me, in current
case:
- init section is the last section of kernel, l1.text is within init
section, and it is in the fixed address. The other contents before
l1.text are dynamic (depend on kernel size).
- if kernel is too big, the contents before l1.text (the other contents
in .init.text) will override it, so ld reports issues.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On Wed, Apr 22, 2015 at 10:32 PM, Chen Gang <[email protected]> wrote:
> On 4/22/15 17:00, Steven Miao wrote:
>> Hi,
>>
>> On Thu, Apr 9, 2015 at 5:03 AM, Chen Gang <[email protected]> wrote:
>>> l1_text is at L1_CODE_START (e.g. for bf533, 0xff800000). If the kernel
>>> is too big, it may be overwritten, the related issue:
>>>
>>> LD init/built-in.o
>>> init/built-in.o: In function `do_early_param':
>>> init/main.c:(.init.text+0xe0): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
>>> init/main.c:(.init.text+0x10e): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
>> blackfin toolchain generate 24 bit pc-relative calls by default, with
>> a range of –16,777,216 through 16,777,214 (0xFF00 0000 to 0x00FF FFFE)
>> is available.
>> So call to l1_text should be ok. What do you mean the kernel is too big?
>> http://docs.blackfin.uclinux.org/doku.php?id=ism:call
>>
>>
>
> Excuse me, I am not quite familiar with what you said above, can we
> also treat 24-bit as 16MB size limitation for kernel size? I am not
> quite sure, could you provide more information about it?.
>
> And I checked "arch/blackfin/kernel/vmlinux.lds.S", for me, in current
> case:
The memory address on blackfin usually starts from 0, if pc = 0, the
pc relative call range is [0xFF00 0000 - 0xFFFFFFFF, 0 - 0x00FF
FFFE], it covers L1 space.
If the kernel is big than 16M, eg. pc = 0x100 0000, the pc relative
call range accordingly is [0x1 - 0x100 0000, 0x100 0000 - 0x 1FF FFFE
], it cann't call to L1 space.
>
> - init section is the last section of kernel, l1.text is within init
> section, and it is in the fixed address. The other contents before
> l1.text are dynamic (depend on kernel size).
>
> - if kernel is too big, the contents before l1.text (the other contents
> in .init.text) will override it, so ld reports issues.
>
>
> Thanks.
> --
> Chen Gang
>
> Open, share, and attitude like air, water, and life which God blessed
On 4/23/15 10:51, Steven Miao wrote:
> On Wed, Apr 22, 2015 at 10:32 PM, Chen Gang <[email protected]> wrote:
>> On 4/22/15 17:00, Steven Miao wrote:
>>> Hi,
>>>
>>> On Thu, Apr 9, 2015 at 5:03 AM, Chen Gang <[email protected]> wrote:
>>>> l1_text is at L1_CODE_START (e.g. for bf533, 0xff800000). If the kernel
>>>> is too big, it may be overwritten, the related issue:
>>>>
>>>> LD init/built-in.o
>>>> init/built-in.o: In function `do_early_param':
>>>> init/main.c:(.init.text+0xe0): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
>>>> init/main.c:(.init.text+0x10e): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
>>> blackfin toolchain generate 24 bit pc-relative calls by default, with
>>> a range of –16,777,216 through 16,777,214 (0xFF00 0000 to 0x00FF FFFE)
>>> is available.
>>> So call to l1_text should be ok. What do you mean the kernel is too big?
>>> http://docs.blackfin.uclinux.org/doku.php?id=ism:call
>>>
>>>
>>
>> Excuse me, I am not quite familiar with what you said above, can we
>> also treat 24-bit as 16MB size limitation for kernel size? I am not
>> quite sure, could you provide more information about it?.
>>
>> And I checked "arch/blackfin/kernel/vmlinux.lds.S", for me, in current
>> case:
> The memory address on blackfin usually starts from 0, if pc = 0, the
> pc relative call range is [0xFF00 0000 - 0xFFFFFFFF, 0 - 0x00FF
> FFFE], it covers L1 space.
> If the kernel is big than 16M, eg. pc = 0x100 0000, the pc relative
> call range accordingly is [0x1 - 0x100 0000, 0x100 0000 - 0x 1FF FFFE
> ], it cann't call to L1 space.
OK, thanks. I guess your meaning is:
- If the kernel is too big, it may let the pc which wants to call L1
space fail.
- So the kernel is too big to cause this issue, but it is nothing with
'overwritten' in my original patch comments.
- We can treat it as environments limitation, then can use COMPILE_TEST
for it. So this patch is still OK, except the related comments need
be improved (at least need to remove 'overwritten').
>>
>> - init section is the last section of kernel, l1.text is within init
>> section, and it is in the fixed address. The other contents before
>> l1.text are dynamic (depend on kernel size).
>>
I guess, what I said above is meaningless (although it is correct).
>> - if kernel is too big, the contents before l1.text (the other contents
>> in .init.text) will override it, so ld reports issues.
I guess, what I said above is incorrect.
Are all of I guesses correct?
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On Thu, Apr 23, 2015 at 10:30 PM, Chen Gang <[email protected]> wrote:
> On 4/23/15 10:51, Steven Miao wrote:
>> On Wed, Apr 22, 2015 at 10:32 PM, Chen Gang <[email protected]> wrote:
>>> On 4/22/15 17:00, Steven Miao wrote:
>>>> Hi,
>>>>
>>>> On Thu, Apr 9, 2015 at 5:03 AM, Chen Gang <[email protected]> wrote:
>>>>> l1_text is at L1_CODE_START (e.g. for bf533, 0xff800000). If the kernel
>>>>> is too big, it may be overwritten, the related issue:
>>>>>
>>>>> LD init/built-in.o
>>>>> init/built-in.o: In function `do_early_param':
>>>>> init/main.c:(.init.text+0xe0): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
>>>>> init/main.c:(.init.text+0x10e): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o)
>>>> blackfin toolchain generate 24 bit pc-relative calls by default, with
>>>> a range of –16,777,216 through 16,777,214 (0xFF00 0000 to 0x00FF FFFE)
>>>> is available.
>>>> So call to l1_text should be ok. What do you mean the kernel is too big?
>>>> http://docs.blackfin.uclinux.org/doku.php?id=ism:call
>>>>
>>>>
>>>
>>> Excuse me, I am not quite familiar with what you said above, can we
>>> also treat 24-bit as 16MB size limitation for kernel size? I am not
>>> quite sure, could you provide more information about it?.
>>>
>>> And I checked "arch/blackfin/kernel/vmlinux.lds.S", for me, in current
>>> case:
>> The memory address on blackfin usually starts from 0, if pc = 0, the
>> pc relative call range is [0xFF00 0000 - 0xFFFFFFFF, 0 - 0x00FF
>> FFFE], it covers L1 space.
>> If the kernel is big than 16M, eg. pc = 0x100 0000, the pc relative
>> call range accordingly is [0x1 - 0x100 0000, 0x100 0000 - 0x 1FF FFFE
>> ], it cann't call to L1 space.
>
> OK, thanks. I guess your meaning is:
>
> - If the kernel is too big, it may let the pc which wants to call L1
> space fail.
>
> - So the kernel is too big to cause this issue, but it is nothing with
> 'overwritten' in my original patch comments.
>
Yes, it is.
> - We can treat it as environments limitation, then can use COMPILE_TEST
> for it. So this patch is still OK, except the related comments need
> be improved (at least need to remove 'overwritten').
>
If pc-relative CALL will fail, there will be "relocation truncated to
fit: R_BFIN_PCREL24" warnings.
>>>
>>> - init section is the last section of kernel, l1.text is within init
>>> section, and it is in the fixed address. The other contents before
>>> l1.text are dynamic (depend on kernel size).
>>>
>
> I guess, what I said above is meaningless (although it is correct).
>
>>> - if kernel is too big, the contents before l1.text (the other contents
>>> in .init.text) will override it, so ld reports issues.
>
Actually the kernel which is large the 16M could not happen, large
size kernel image is not sugguested on a embedded system.
> I guess, what I said above is incorrect.
>
>
> Are all of I guesses correct?
>
>
> Thanks.
> --
> Chen Gang
>
> Open, share, and attitude like air, water, and life which God blessed
-steven
On 4/24/15 16:20, Steven Miao wrote:
> On Thu, Apr 23, 2015 at 10:30 PM, Chen Gang <[email protected]> wrote:
>>
>> OK, thanks. I guess your meaning is:
>>
>> - If the kernel is too big, it may let the pc which wants to call L1
>> space fail.
>>
>> - So the kernel is too big to cause this issue, but it is nothing with
>> 'overwritten' in my original patch comments.
>>
> Yes, it is.
OK, thanks.
>> - We can treat it as environments limitation, then can use COMPILE_TEST
>> for it. So this patch is still OK, except the related comments need
>> be improved (at least need to remove 'overwritten').
>>
> If pc-relative CALL will fail, there will be "relocation truncated to
> fit: R_BFIN_PCREL24" warnings.
OK, thanks. for me, we need to skip these warnings when COMPILE_TEST
is set, so can continue compiling (or will cause building break).
>>
>> I guess, what I said above is meaningless (although it is correct).
>>
>>>> - if kernel is too big, the contents before l1.text (the other contents
>>>> in .init.text) will override it, so ld reports issues.
>>
> Actually the kernel which is large the 16M could not happen, large
> size kernel image is not sugguested on a embedded system.
>
OK, thanks. So for me, it should only happen when COMPILE_TEST is set,
should not happen in real world using.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed