* some question about output section
@ 2011-04-27 15:29 loody
2011-04-28 0:57 ` Alan Modra
0 siblings, 1 reply; 14+ messages in thread
From: loody @ 2011-04-27 15:29 UTC (permalink / raw)
To: binutils
Dear all:
I have some questions as below:
1. Is it possible to put whole .text of a static library to one output section?
2. Is it possible to put whole sections of a static library to one
output section?
3. is it possible for some file B to get address of some function in
A, while linking?
4. usually the address of a static lib is not determined until link
stage. Is it possible we can pre-defined the address of each function
in a static lib?
( I try to describe my environment with pseudo code as below)
file A, entry= 0xbf000000
.text (exclude lib1.a)
VMA(.text of lib1.a) = 0xbf100000
LMA(.text of lib1.a) = behind of .text
VMA(whole sections of lib2.a) = 0x80000000
LMA(whole sections of lib2.a) = behind of lib1.a
.data
......
file B, entry= 0xbfa00000
call function c in lib1.a
--
Regards,
miloody
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-04-27 15:29 some question about output section loody
@ 2011-04-28 0:57 ` Alan Modra
2011-04-28 16:17 ` loody
0 siblings, 1 reply; 14+ messages in thread
From: Alan Modra @ 2011-04-28 0:57 UTC (permalink / raw)
To: loody; +Cc: binutils
On Wed, Apr 27, 2011 at 11:29:13PM +0800, loody wrote:
> Dear all:
> I have some questions as below:
> 1. Is it possible to put whole .text of a static library to one output section?
> 2. Is it possible to put whole sections of a static library to one
> output section?
> 3. is it possible for some file B to get address of some function in
> A, while linking?
> 4. usually the address of a static lib is not determined until link
> stage. Is it possible we can pre-defined the address of each function
> in a static lib?
Yes, yes, yes and yes. As to how you can do this, see ld info doc
node "Input Section Basics" for the answer to (1) and (2). For (3)
and (4) you're going to need to compile with -ffunction-sections then
write scripts to put the functions where you want them. An
alternative to (4) is to build a jump table at a fixed address then
define the function entry points on the jump table entries.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-04-28 0:57 ` Alan Modra
@ 2011-04-28 16:17 ` loody
2011-04-29 0:32 ` Alan Modra
0 siblings, 1 reply; 14+ messages in thread
From: loody @ 2011-04-28 16:17 UTC (permalink / raw)
To: amodra, binutils
hi:
2011/4/28 Alan Modra <amodra@gmail.com>:
> On Wed, Apr 27, 2011 at 11:29:13PM +0800, loody wrote:
>> Dear all:
>> I have some questions as below:
>> 1. Is it possible to put whole .text of a static library to one output section?
>> 2. Is it possible to put whole sections of a static library to one
>> output section?
>> 3. is it possible for some file B to get address of some function in
>> A, while linking?
>> 4. usually the address of a static lib is not determined until link
>> stage. Is it possible we can pre-defined the address of each function
>> in a static lib?
>
> Yes, yes, yes and yes. As to how you can do this, see ld info doc
> node "Input Section Basics" for the answer to (1) and (2). For (3)
> and (4) you're going to need to compile with -ffunction-sections then
> write scripts to put the functions where you want them. An
> alternative to (4) is to build a jump table at a fixed address then
> define the function entry points on the jump table entries.
>
after studying the ld info, I make a link script as below:
OUTPUT_ARCH(mips)
ENTRY(entry)
SECTIONS
{
.begin 0xbfb00000 :
{
*(.begin)
. = ALIGN(8);
_end_begin = ABSOLUTE(.);
}
.onlyText 0x80000000 : AT(_end_begin)
{
lib1.a ( *.text )
}
.wholelib 0x81000000 :
{
lib2.a (*)
}
.text : { *(EXCLUDE_FILE (*.a ) .text)}
.data : { *(EXCLUDE_FILE (*.a ) .data) }
}
and I link the files by following command.
mipsel-linux-gnu-ld -T ./link.xn -o TEST_LINK.elf -Map TEST_LINK.map
--oformat elf32-tradlittlemips lib1.a lib2.a main.o ut.o
But I cannot see the section I used to link lib1.a and lib2.a
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0xbfb00000
Start of program headers: 52 (bytes into file)
Start of section headers: 2936 (bytes into file)
Flags: 0x70001001, noreorder, o32, mips32r2
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 20
Section header string table index: 17
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .begin PROGBITS bfb00000 000054 000058 00 AX 0 0 4
[ 2] .text PROGBITS bfb00058 0000ac 0002bc 00 AX 0 0 4
[ 3] .rodata.str1.4 PROGBITS bfb00314 000368 000014 01 AMS 0 0 4
[ 4] .data PROGBITS bfb00328 00037c 000014 00 WA 0 0 4
[ 5] .bss NOBITS bfb0033c 000390 000004 00 WA 0 0 4
[ 6] .reginfo MIPS_REGINFO 00000000 000390 000018 18 0 0 4
[ 7] .pdr PROGBITS 00000000 0003a8 0000a0 00 0 0 4
[ 8] .mdebug.abi32 PROGBITS 00000000 000448 000000 00 0 0 1
[ 9] .debug_abbrev MIPS_DWARF 00000000 000448 0000fa 00 0 0 1
[10] .debug_info MIPS_DWARF 00000000 000542 0001b8 00 0 0 1
[11] .debug_line MIPS_DWARF 00000000 0006fa 0000bf 00 0 0 1
[12] .debug_frame MIPS_DWARF 00000000 0007bc 000080 00 0 0 4
[13] .debug_pubnames MIPS_DWARF 00000000 00083c 000083 00 0 0 1
[14] .debug_aranges MIPS_DWARF 00000000 0008bf 000048 00 0 0 1
[15] .debug_str MIPS_DWARF 00000000 000907 000154 01 MS 0 0 1
[16] .comment PROGBITS 00000000 000a5b 000056 00 0 0 1
[17] .shstrtab STRTAB 00000000 000ab1 0000c4 00 0 0 1
[18] .symtab SYMTAB 00000000 000e98 0001e0 10 19 24 4
[19] .strtab STRTAB 00000000 001078 00007a 00 0 0 1
Did I miss anything?
--
Regards,
miloody
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-04-28 16:17 ` loody
@ 2011-04-29 0:32 ` Alan Modra
2011-05-01 13:21 ` loody
0 siblings, 1 reply; 14+ messages in thread
From: Alan Modra @ 2011-04-29 0:32 UTC (permalink / raw)
To: loody; +Cc: binutils
On Fri, Apr 29, 2011 at 12:17:18AM +0800, loody wrote:
> after studying the ld info
Study some more. Also review when ld extracts elements from archives.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-04-29 0:32 ` Alan Modra
@ 2011-05-01 13:21 ` loody
2011-05-04 15:51 ` loody
0 siblings, 1 reply; 14+ messages in thread
From: loody @ 2011-05-01 13:21 UTC (permalink / raw)
To: binutils, amodra
hi:
Thanks for your kind hint :-)
2011/4/29 Alan Modra <amodra@gmail.com>:
> On Fri, Apr 29, 2011 at 12:17:18AM +0800, loody wrote:
>> after studying the ld info
>
> Study some more. Also review when ld extracts elements from archives.
>
after studying the section 3.6.4.1 about specifying files in the
archives by writing a pattern.
I changed my ld script as below and put some object files below link_folder:
OUTPUT_ARCH(mips)
ENTRY(entry)
SECTIONS
{
.begin 0xbfb00000 :
{
*(.begin)
. = ALIGN(8);
_end_begin = ABSOLUTE(.);
}
.onlyText 0x80000000 : /*AT(_end_begin)*/
{
link_folder: (*.text)
lib1.a:(*.text)
}
.wholelib 0x81000000 :
{
lib2.a:
}
.text : { *(EXCLUDE_FILE (*.a ) .text)}
.data : { *(EXCLUDE_FILE (*.a ) .data) }
}
# ls link_folder/ -lht
total 12K
-rw-r--r-- 1 root root 4.8K 2011-05-01 20:42 file1.o
-rw-r--r-- 1 root root 3.7K 2011-05-01 20:42 main.o
#
I still cannot find the section name, onlyText and wholelib, in my elf
content with link command as below:
mipsel-linux-gnu-ld -T ./link.xn -o TEST_LINK.elf -Map TEST_LINK.map
--oformat elf32-tradlittlemips lib1.a lib2.a file1.o main.o
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .begin PROGBITS bfb00000 010000 000070 00 AX 0 0 4
[ 2] .text PROGBITS bfb00070 010070 0002a0 00 AX 0 0 16
[ 3] .reginfo MIPS_REGINFO bfb00310 010310 000018 18 A 0 0 4
[ 4] .rodata PROGBITS bfb00330 010330 000020 00 A 0 0 16
[ 5] .rodata.str1.4 PROGBITS bfb00350 010350 000014 01 AMS 0 0 4
[ 6] .bss NOBITS bfb00370 010364 000010 00 WA 0 0 16
[ 7] .pdr PROGBITS 00000000 010364 0000a0 00 0 0 4
[ 8] .comment PROGBITS 00000000 010404 00007a 00 0 0 1
[ 9] .gnu.attributes LOOS+ffffff5 00000000 01047e 000010 00 0 0 1
[10] .debug_abbrev MIPS_DWARF 00000000 01048e 000161 00 0 0 1
[11] .debug_info MIPS_DWARF 00000000 0105ef 0001eb 00 0 0 1
[12] .debug_line MIPS_DWARF 00000000 0107da 0000d0 00 0 0 1
[13] .debug_frame MIPS_DWARF 00000000 0108ac 000080 00 0 0 4
[14] .debug_loc MIPS_DWARF 00000000 01092c 00019c 00 0 0 1
[15] .debug_pubnames MIPS_DWARF 00000000 010ac8 000083 00 0 0 1
[16] .debug_aranges MIPS_DWARF 00000000 010b4b 000040 00 0 0 1
[17] .debug_str MIPS_DWARF 00000000 010b8b 000141 01 MS 0 0 1
[18] .debug_ranges MIPS_DWARF 00000000 010ccc 000018 00 0 0 1
[19] .shstrtab STRTAB 00000000 010ce4 0000e1 00 0 0 1
[20] .symtab SYMTAB 00000000 011138 0001d0 10 21 23 4
[21] .strtab STRTAB 00000000 011308 00007d 00 0 0 1
Key to Flags:
--
Regards,
miloody
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-05-01 13:21 ` loody
@ 2011-05-04 15:51 ` loody
2011-05-05 0:35 ` Alan Modra
0 siblings, 1 reply; 14+ messages in thread
From: loody @ 2011-05-04 15:51 UTC (permalink / raw)
To: binutils, amodra
hi all:
2011/5/1 loody <miloody@gmail.com>:
> hi:
> Thanks for your kind hint :-)
>
> 2011/4/29 Alan Modra <amodra@gmail.com>:
>> On Fri, Apr 29, 2011 at 12:17:18AM +0800, loody wrote:
>>> after studying the ld info
>>
>> Study some more. Also review when ld extracts elements from archives.
>>
Below I excerpt the content of the document
‘archive:file’
matches file within archive
‘archive:’
matches the whole archive
And I make 2 links script to link all the *.o files below link_folder
1.
OUTPUT_ARCH(mips)
SECTIONS
{
.onlyText 0x80000000 :{ link_folder:*.o (.text) }
}
ld tell me he cannot find "input files" by this script
mipsel-linux-gnu-ld -Bstatic -T ./link.xn -o TEST_LINK.elf -Map
TEST_LINK.map --oformat elf32-tradlittlemips
mipsel-linux-gnu-ld: no input files
2,
OUTPUT_ARCH(mips)
SECTIONS
{
.onlyText 0x80000000 : { link_folder: (.text) }
}
ld can successfully generate elf file for me, but I cannot see the
output section I give in script.
Below are the contents of ./link_folder
# ls link_folder/ -lht
total 12K
-rw-r--r-- 1 root root 4.8K 2011-05-04 21:29 file1.o
-rw-r--r-- 1 root root 3.7K 2011-05-04 21:29 main.o
#
My questions are:
1. in document, it say "Either one or both of `archive' and `file' can
contain shell wildcards." In my script1, I wrote the 'file' part to
meet all *.o files. Why ld told me he cannot find them?
2. in script2, I follow the rule " `archive:' matches the whole
archive". So ld doesn't tell me he cannot find them, But why final elf
still don't include the section I wrote in script, furthermore, the
elf doesn't any .text .data .bss secion.
3. I think "lib1.a:" is not the correct usage to tell ld to search for
the object files content in lib1.a, since lib1.a is not an archive,
right? (I thought archive here in document means real folder)
appreciate your kind help,
miloody
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-05-04 15:51 ` loody
@ 2011-05-05 0:35 ` Alan Modra
2011-05-05 3:00 ` loody
0 siblings, 1 reply; 14+ messages in thread
From: Alan Modra @ 2011-05-05 0:35 UTC (permalink / raw)
To: loody; +Cc: binutils
On Wed, May 04, 2011 at 11:51:24PM +0800, loody wrote:
> right? (I thought archive here in document means real folder)
It means what it says. An archive is a file created by "ar", not
a directory/folder.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-05-05 0:35 ` Alan Modra
@ 2011-05-05 3:00 ` loody
2011-05-05 3:57 ` Alan Modra
0 siblings, 1 reply; 14+ messages in thread
From: loody @ 2011-05-05 3:00 UTC (permalink / raw)
To: amodra, binutils
hi:
2011/5/5 Alan Modra <amodra@gmail.com>:
> On Wed, May 04, 2011 at 11:51:24PM +0800, loody wrote:
>> right? (I thought archive here in document means real folder)
>
> It means what it says. An archive is a file created by "ar", not
> a directory/folder.
Thank you.
it seems I misunderstand the meaning of "archive" in the document. :P
So I change the script as below:
OUTPUT_ARCH(mips)
SECTIONS
{
.onlyText 0x80000000 : { lib2.a:*.o (*.text) }
}
OUTPUT_ARCH(mips)
SECTIONS
{
.onlyText 0x80000000 : { lib2.a: (*.text) }
}
and link command as:
mipsel-linux-gnu-ld -Bstatic -T ./link.xn -o TEST_LINK.elf -Map
TEST_LINK.map --oformat elf32-tradlittlemips lib2.a
but I still cannot see the section I named in the script file shows up
in final elf.
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .shstrtab STRTAB 00000000 000034 00001b 00 0 0 1
[ 2] .symtab SYMTAB 00000000 0000f0 000010 10 3 1 4
[ 3] .strtab STRTAB 00000000 000100 000001 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)
below is the content of lib2.a
#nm lib2.a
sdc.o:
0000002c T DRV_SDC_CardStatus_Inserted
0000003c T DRV_SDC_SysInit
00000400 T MOVE_BOOT_CODE_BY_SOFTWARE
0000052c T MOVE_BOOT_CODE_BY_SOFTWARE_With_Setting
U OS_DelayTime
000000a4 T SDC_CMD0_With_ARG
000000e4 T SDC_InitClock
000001c0 T SDC_ReadSector_Boot
00000000 T _SDC_PowerOn
00000000 b dwClkDivisor
00000014 T Enter
U inv_dcache_range
--
Regards,
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-05-05 3:00 ` loody
@ 2011-05-05 3:57 ` Alan Modra
2011-05-11 6:27 ` loody
0 siblings, 1 reply; 14+ messages in thread
From: Alan Modra @ 2011-05-05 3:57 UTC (permalink / raw)
To: loody; +Cc: binutils
On Thu, May 05, 2011 at 11:00:01AM +0800, loody wrote:
> .onlyText 0x80000000 : { lib2.a:*.o (*.text) }
So this tells ld where to put lib2.a object files,
> mipsel-linux-gnu-ld -Bstatic -T ./link.xn -o TEST_LINK.elf -Map
> TEST_LINK.map --oformat elf32-tradlittlemips lib2.a
and the above says to extract files from lib2.a if they satisfy
undefined references at the point where lib2.a is searched in the link
process. That is the way archives work. You don't have any other
object files or -u command line options, so no undefined symbol
references! You'll need --whole-archive to have the entire contents
of the archive extracted.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-05-05 3:57 ` Alan Modra
@ 2011-05-11 6:27 ` loody
2011-05-11 7:18 ` Alan Modra
0 siblings, 1 reply; 14+ messages in thread
From: loody @ 2011-05-11 6:27 UTC (permalink / raw)
To: amodra, binutils
hi:
2011/5/5 Alan Modra <amodra@gmail.com>:
> On Thu, May 05, 2011 at 11:00:01AM +0800, loody wrote:
>> .onlyText 0x80000000 : { lib2.a:*.o (*.text) }
>
> So this tells ld where to put lib2.a object files,
>
>> mipsel-linux-gnu-ld -Bstatic -T ./link.xn -o TEST_LINK.elf -Map
>> TEST_LINK.map --oformat elf32-tradlittlemips lib2.a
>
> and the above says to extract files from lib2.a if they satisfy
> undefined references at the point where lib2.a is searched in the link
> process. That is the way archives work. You don't have any other
> object files or -u command line options, so no undefined symbol
> references! You'll need --whole-archive to have the entire contents
> of the archive extracted.
>
It did work after I add some object files to let linker to find the
undefined references when lib2.a searched. :P
Meanwhile:
I have some questions below:
1. I found if the address between 2 sections is too large, the objcopy will
automatically fill the gap and the size of final binary file will quite big.
There is a thread below mention about this:
http://sourceware.org/ml/binutils/2008-11/msg00316.html
does that mean the only way I can to do is outputting each section one
by one and merge them by myself?
2. I found if the LMA of 2 sections are quite close, the size of
objcopy will get small, script1.
But why if the LMA of third section is close to previous section, the
size will still get big, script2?
/*script 1 */
OUTPUT_ARCH(mips)
SECTIONS
{
.text 0xbfc00000:
{ *(EXCLUDE_FILE (*.a) .text) } = 0
_etext = ABSOLUTE(.);
.onlyText 0x80000000: AT( _etext ) { lib1.a:*.o (*.text)
_eonlytext = ABSOLUTE(.); } =0
}
/*script 2*/
OUTPUT_ARCH(mips)
SECTIONS
{
.text 0xbfc00000:{ *(EXCLUDE_FILE (*.a) .text) } = 0
_etext = ABSOLUTE(.);
.onlyText 0x80000000: AT( _etext ) { lib1.a:*.o
(*.text) _eonlytext = ABSOLUTE(.); } =0
.onlyData : AT(_eonlytext) { lib1.a:*.o (*.data) }
}
Appreciate your kind help :-)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-05-11 6:27 ` loody
@ 2011-05-11 7:18 ` Alan Modra
2011-05-11 8:12 ` loody
2011-05-18 5:32 ` loody
0 siblings, 2 replies; 14+ messages in thread
From: Alan Modra @ 2011-05-11 7:18 UTC (permalink / raw)
To: loody; +Cc: binutils
On Wed, May 11, 2011 at 02:27:09PM +0800, loody wrote:
> 2. I found if the LMA of 2 sections are quite close, the size of
> objcopy will get small, script1.
> But why if the LMA of third section is close to previous section, the
> size will still get big, script2?
Why do you think the LMAs are close?
Your scripts are setting LMA of a section to the end VMA of the
previous section. I suspect that wasn't what you intended.
See ld.info LOADADDR and SIZEOF.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-05-11 7:18 ` Alan Modra
@ 2011-05-11 8:12 ` loody
2011-05-18 5:32 ` loody
1 sibling, 0 replies; 14+ messages in thread
From: loody @ 2011-05-11 8:12 UTC (permalink / raw)
To: amodra, binutils
HI:
2011/5/11 Alan Modra <amodra@gmail.com>:
> On Wed, May 11, 2011 at 02:27:09PM +0800, loody wrote:
>> 2. I found if the LMA of 2 sections are quite close, the size of
>> objcopy will get small, script1.
>> But why if the LMA of third section is close to previous section, the
>> size will still get big, script2?
>
> Why do you think the LMAs are close?
I think it will be better if I say "the binary size that objcopy
generate is quite small, when the LMA of section2 is right behind the
section1."
>
> Your scripts are setting LMA of a section to the end VMA of the
> previous section. I suspect that wasn't what you intended.
in script2, "text' is the place that flash running for and "onlyTest"
is located at dram area.
That means, I can put some functions that need performance in
"onlyTest" and this part of code will copy to dram at the end of
"text" section.
> See ld.info LOADADDR and SIZEOF.
>
Thank you,
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-05-11 7:18 ` Alan Modra
2011-05-11 8:12 ` loody
@ 2011-05-18 5:32 ` loody
2011-05-19 4:31 ` loody
1 sibling, 1 reply; 14+ messages in thread
From: loody @ 2011-05-18 5:32 UTC (permalink / raw)
To: amodra, binutils
hi
2011/5/11 Alan Modra <amodra@gmail.com>:
> On Wed, May 11, 2011 at 02:27:09PM +0800, loody wrote:
>> 2. I found if the LMA of 2 sections are quite close, the size of
>> objcopy will get small, script1.
>> But why if the LMA of third section is close to previous section, the
>> size will still get big, script2?
>
> Why do you think the LMAs are close?
>
> Your scripts are setting LMA of a section to the end VMA of the
> previous section. I suspect that wasn't what you intended.
> See ld.info LOADADDR and SIZEOF.
>
I finally figured out what you mean :)
I use MEMORY command in my ld script, and I found the LMA of one
section will right behind previous one, even I didn't tell the script
to do so.
below is some part of my ld script:
MEMORY
{
region0 : org = 0xbfc00000, l = 24k
region1 : org = 0xbfc06000, l = 26k
region2 : org = 0xbfb04000, l = 14k
region3 : org = 0x80000000, l = 64k
}
....
.onlyText : { lib1.a:*.o (*.text) _eonlytext =
ABSOLUTE(.); } >region2 AT>region0
. = ALIGN(4);
_fbss = .;
.sbss : { *(.sbss) *(.scommon) *(.bss) *(COMMON) } >region2
...
Below is the output of map:
.sbss 0x00000000bfb05540 0x60 load address 0x00000000bfc0187c
*(.sbss)
*(.scommon)
.scommon 0x00000000bfb05540 0x4 main.o
It seem ".sbss" adopt the same setting of .onlyText even I didn't at
AT>region0 at the end.
appreciate your help,
miloody
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: some question about output section
2011-05-18 5:32 ` loody
@ 2011-05-19 4:31 ` loody
0 siblings, 0 replies; 14+ messages in thread
From: loody @ 2011-05-19 4:31 UTC (permalink / raw)
To: amodra, binutils
hi:
2011/5/18 loody <miloody@gmail.com>:
> hi
> 2011/5/11 Alan Modra <amodra@gmail.com>:
>> On Wed, May 11, 2011 at 02:27:09PM +0800, loody wrote:
>>> 2. I found if the LMA of 2 sections are quite close, the size of
>>> objcopy will get small, script1.
>>> But why if the LMA of third section is close to previous section, the
>>> size will still get big, script2?
>>
>> Why do you think the LMAs are close?
>>
>> Your scripts are setting LMA of a section to the end VMA of the
>> previous section. I suspect that wasn't what you intended.
>> See ld.info LOADADDR and SIZEOF.
>>
>
> I finally figured out what you mean :)
>
> I use MEMORY command in my ld script, and I found the LMA of one
> section will right behind previous one, even I didn't tell the script
> to do so.
>
> below is some part of my ld script:
> MEMORY
> {
> region0 : org = 0xbfc00000, l = 24k
> region1 : org = 0xbfc06000, l = 26k
> region2 : org = 0xbfb04000, l = 14k
> region3 : org = 0x80000000, l = 64k
> }
> ....
> .onlyText : { lib1.a:*.o (*.text) _eonlytext =
> ABSOLUTE(.); } >region2 AT>region0
>
> . = ALIGN(4);
> _fbss = .;
> .sbss : { *(.sbss) *(.scommon) *(.bss) *(COMMON) } >region2
>
> ...
>
>
> Below is the output of map:
> .sbss 0x00000000bfb05540 0x60 load address 0x00000000bfc0187c
> *(.sbss)
> *(.scommon)
> .scommon 0x00000000bfb05540 0x4 main.o
>
>
> It seem ".sbss" adopt the same setting of .onlyText even I didn't at
> AT>region0 at the end.
>
> appreciate your help,
> miloody
I do the following experimemts:
1. assign address directly instead of using MEMORY comamnd
".sbss" still adopt the same setting of .onlyText
.onlyText 0x00000000bfb04000 0x70 load address 0x00000000bfc0030c
Zebra*(.text)
.text 0x00000000bfb04000 0x70 Zebra.o
0x00000000bfb04000 testmain1
0x00000000bfb04070 _eonlytext = ABSOLUTE (.)
0x00000000bfb04070 . = ALIGN (0x4)
0x00000000bfb04070 _fbss = .
.sbss 0x00000000bfb04070 0x4 load address 0x00000000bfc0037c
*(.sbss)
*(.scommon)
2. I purposely let the content of .onlyText be empty and ".sbss" will
have the LMA that I expected.
------------------------------------------------------------------------------
.onlyText 0xbfb04000:AT(_etext) { /* Zebra*(.text)*/
_eonlytext =
ABSOLUTE(.); }
. = ALIGN(4);
_fbss = .;
.sbss : { *(.sbss) *(.scommon) *(.bss) *(COMMON) }
-------------------------------------------------------------------------------
.onlyText 0x00000000bfb04000 0x0 load address 0x00000000bfc00380
0x00000000bfb04000 _eonlytext = ABSOLUTE (.)
0x00000000bfb04000 . = ALIGN (0x4)
0x00000000bfb04000 _fbss = .
.sbss 0x00000000bfb04000 0x4
*(.sbss)
*(.scommon)
.scommon 0x00000000bfb04000 0x4 main.o
Why the attributes of .sbss is depended on the size of previous section?
If I didn't assign the LMA address of .sbss, it should be reset
instead of using the end of previous one, right?
Thanks a lot,
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-05-19 4:31 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-27 15:29 some question about output section loody
2011-04-28 0:57 ` Alan Modra
2011-04-28 16:17 ` loody
2011-04-29 0:32 ` Alan Modra
2011-05-01 13:21 ` loody
2011-05-04 15:51 ` loody
2011-05-05 0:35 ` Alan Modra
2011-05-05 3:00 ` loody
2011-05-05 3:57 ` Alan Modra
2011-05-11 6:27 ` loody
2011-05-11 7:18 ` Alan Modra
2011-05-11 8:12 ` loody
2011-05-18 5:32 ` loody
2011-05-19 4:31 ` loody
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).