some question about output section

some question about output section

[loody]

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

Re: some question about output section

[Alan Modra]

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

Re: some question about output section

[loody]

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

Re: some question about output section

[Alan Modra]

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

Re: some question about output section

[loody]

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

Re: some question about output section

[loody]

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

Re: some question about output section

[Alan Modra]

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

Re: some question about output section

[loody]

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,

Re: some question about output section

[Alan Modra]

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

Re: some question about output section

[loody]

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 :-)

Re: some question about output section

[Alan Modra]

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

Re: some question about output section

[loody]

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,

Re: some question about output section

[loody]

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

Re: some question about output section

[loody]

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,