[ELDK] Compilation problems with ppc_85xx- of ELDK42 tool chain
krish
radhakrishna.p at gmail.com
Mon Jul 18 10:14:05 CEST 2011
Hi Folks,
I have solved my problem by using "-mlongcall" compile option and "--relax"
linker option.
Thanks for your support.
On Fri, Jul 15, 2011 at 3:33 PM, krish <radhakrishna.p at gmail.com> wrote:
> Dear Wolfgang,
>
> I compiled source for host build and fund that the .text section is equal
> to 49MB and .debug_info is also crossing the 32MB limit.
>
> I have already tried "-mlongcall" option while compiling for PPC. Problem
> still present.
> Please help me in solving this problem?
>
> Is it make sense to upgrade "binutils" to newer version ? I am not sure. I
> got some information through google search.
>
> Below is the output of "readelf --sections" of my image (host build).
> There are 40 section headers, starting at offset 0x95073b0:
>
> Section Headers:
> [Nr] Name Type Addr Off Size ES Flg Lk
> Inf Al
> [ 0] NULL 00000000 000000 000000 00 0
> 0 0
> [ 1] .interp PROGBITS 08048134 000134 000013 00 A 0
> 0 1
> [ 2] .note.ABI-tag NOTE 08048148 000148 000020 00 A 0
> 0 4
> [ 3] .note.gnu.build-i NOTE 08048168 000168 000024 00 A 0
> 0 4
> [ 4] .hash HASH 0804818c 00018c 0050a0 04 A 6
> 0 4
> [ 5] .gnu.hash GNU_HASH 0804d22c 00522c 0056e8 04 A 6
> 0 4
> [ 6] .dynsym DYNSYM 08052914 00a914 00c210 10 A 7
> 1 4
> [ 7] .dynstr STRTAB 0805eb24 016b24 011a55 00 A 0
> 0 1
> [ 8] .gnu.version VERSYM 0807057a 02857a 001842 02 A 6
> 0 2
> [ 9] .gnu.version_r VERNEED 08071dbc 029dbc 0000b0 00 A 7
> 3 4
> [10] .rel.dyn REL 08071e6c 029e6c 005d98 08 A 6
> 0 4
> [11] .rel.plt REL 08077c04 02fc04 000360 08 A 6
> 13 4
> [12] .init PROGBITS 08077f64 02ff64 000030 00 AX 0
> 0 4
> [13] .plt PROGBITS 08077f94 02ff94 0006d0 04 AX 0
> 0 4
> [14] .text PROGBITS 08078670 030670 314a77c 00 AX
> 0 0 16
> [15] .fini PROGBITS 0b1c2dec 317adec 00001c 00 AX
> 0 0 4
> [16] .rodata PROGBITS 0b1c2e20 317ae20 bf9220 00 A
> 0 0 32
> [17] .eh_frame PROGBITS 0bdbc040 3d74040 000004 00 A
> 0 0 4
> [18] .ctors PROGBITS 0bdbd95c 3d7495c 000008 00 WA
> 0 0 4
> [19] .dtors PROGBITS 0bdbd964 3d74964 000008 00 WA
> 0 0 4
> [20] .jcr PROGBITS 0bdbd96c 3d7496c 000004 00 WA
> 0 0 4
> [21] .data.rel.ro PROGBITS 0bdbd980 3d74980 00b6b0 00 WA
> 0 0 32
> [22] .dynamic DYNAMIC 0bdc9030 3d80030 0000e0 08 WA
> 7 0 4
> [23] .got PROGBITS 0bdc9110 3d80110 002ecc 04 WA
> 0 0 4
> [24] .got.plt PROGBITS 0bdcbff4 3d82ff4 0001bc 04 WA
> 0 0 4
> [25] .data PROGBITS 0bdcc1c0 3d831c0 508740 00 WA
> 0 0 32
> [26] .bss NOBITS 0c2d4900 428b900 0582f8 00 WA
> 0 0 32
> [27] .comment PROGBITS 00000000 428b900 000023 01 MS
> 0 0 1
> [28] .debug_aranges PROGBITS 00000000 428b923 01ba20 00
> 0 0 1
> [29] .debug_pubnames PROGBITS 00000000 42a7343 103a89 00
> 0 0 1
> [30] .debug_info PROGBITS 00000000 43aadcc 3f224f8 00
> 0 0 1
> [31] .debug_abbrev PROGBITS 00000000 82cd2c4 1f4c26 00
> 0 0 1
> [32] .debug_line PROGBITS 00000000 84c1eea 65b816 00
> 0 0 1
> [33] .debug_frame PROGBITS 00000000 8b1d700 0b0604 00
> 0 0 4
> [34] .debug_str PROGBITS 00000000 8bcdd04 1695c4 01 MS
> 0 0 1
> [35] .debug_loc PROGBITS 00000000 8d372c8 79def7 00
> 0 0 1
> [36] .debug_ranges PROGBITS 00000000 94d51bf 032080 00
> 0 0 1
> [37] .shstrtab STRTAB 00000000 950723f 000171 00
> 0 0 1
> [38] .symtab SYMTAB 00000000 95079f0 0bf9f0 10 39
> 10764 4
> [39] .strtab STRTAB 00000000 95c73e0 0d9687 00
> 0 0 1
> Key to Flags:
> W (write), A (alloc), X (execute), M (merge), S (strings)
> I (info), L (link order), G (group), x (unknown)
> O (extra OS processing required) o (OS specific), p (processor specific)
>
>
>
>
> On Thu, Jul 14, 2011 at 5:19 PM, krish <radhakrishna.p at gmail.com> wrote:
>
>> Dear Wolfgang,
>>
>> Thanks a lot for your support.
>>
>> We have already tried "-mlongcall" option. Still, it was failed to
>> compile.
>>
>> As I am able to make host build, I will check each segment size.
>> As you suggested, If the data segment is crossing limit, then i will use
>> alternates (malloc or bss section).
>>
>> Once again thanks for your help.
>>
>>
>> On Thu, Jul 14, 2011 at 5:00 PM, Wolfgang Denk <wd at denx.de> wrote:
>>
>>> Dear krish,
>>>
>>> In message <CAH57MOf-T07W=
>>> 3FnBm4CFoNjYJgCyUxeHEOCdj6ULqDgJmYiSQ at mail.gmail.com> you wrote:
>>> >
>>> > Actually, i am facing this problem when i cross compile a third party
>>> stack
>>> > for powerPC. To make my life easy to fix compilation problem, i have
>>> written
>>> > a sample program with data section of 32 MB size.
>>> > Are there any ways(with compilation options) to compile the program
>>> without
>>> > modifying source code?
>>> >
>>> > Is the size limit applicable to all sections. I mean for .text also.?
>>>
>>> The PowerPC relative branch instruction is limited to 24 bit offsets,
>>> i. e. jumps between +/- 32MiB of the current instruction. (24 bits +
>>> 4 bytes = 2 bits per instruction = 26 bit = +/- 32MiB range). Thus
>>> for PPC, relocation is 24-bit; in other words, the absolute value for
>>> the distance from any call to the item called must be less than 2^23
>>> (one bit is the sign).
>>>
>>> For text objects, you might get away with compiler option "-mlongcall"
>>> or "#pragma longall", but note that GCC documentation says these may
>>> go away in later compiler versions.
>>>
>>> For special purposes you might also get away by manually tweaking the
>>> linker script to make sure the relocation only needs to find the start
>>> of your big object, but it's usually better to avoid such huge data
>>> obljects - please keep in mind that this is initialized data, i. e. it
>>> will result in a binary image that is at least as big as well - and in
>>> your example, most of the allocated 32 MiB of date is empty anyway.
>>>
>>> > Could you please provide more information on "why powerpc has this
>>> > limitation?". Is it something related to segment registers and 41-bit
>>> > virtual addressing? In fact, i am looking into PowerPC processor manual
>>> to
>>> > understand the reason for limitation.
>>>
>>> The reason is the 24 bit address offset used in some instructions.
>>>
>>> Best regards,
>>>
>>> Wolfgang Denk
>>>
>>> --
>>> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
>>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>>> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
>>> One difference between a man and a machine is that a machine is quiet
>>> when well oiled.
>>>
>>
>>
>>
>> --
>> Regards,
>> Radha Krishna
>> "Find out what makes you happy and go behind it"
>>
>
>
>
> --
> Regards,
> Radha Krishna
> "Find out what makes you happy and go behind it"
>
--
Regards,
Radha Krishna
"Find out what makes you happy and go behind it"
More information about the eldk
mailing list