[ELDK] Compilation problems with ppc_85xx- of ELDK42 tool chain
krish
radhakrishna.p at gmail.com
Fri Jul 15 12:03:11 CEST 2011
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"
More information about the eldk
mailing list