lkml.org 
[lkml]   [2015]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] blackfin: Makefile: Skip reloc overflow issue when COMPILE_TEST enabled
On 4/23/15 10:51, Steven Miao wrote:
> On Wed, Apr 22, 2015 at 10:32 PM, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>> On 4/22/15 17:00, Steven Miao wrote:
>>> Hi,
>>>
>>> On Thu, Apr 9, 2015 at 5:03 AM, Chen Gang <xili_gchen_5257@hotmail.com> 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


\
 
 \ /
  Last update: 2015-04-23 17:01    [W:0.056 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site