* How to inform the linker not to produce any data for a .bss section?
@ 2007-12-09 2:51 PRC
2007-12-09 20:07 ` Daniel Jacobowitz
0 siblings, 1 reply; 8+ messages in thread
From: PRC @ 2007-12-09 2:51 UTC (permalink / raw)
To: binutils
Here is my link script:
--------------------------------------------------------------------
OUTPUT_ARCH(mips)
SECTIONS
{
.text 0x811ed000 :
{
_dstart = ABSOLUTE(.) ; /* Start of code and data */
*(.libc)
*(.text*)
*(.rodata*)
}
.data :
{
*(.data)
}
.sbss :
{
*(.sbss)
*(.scommon)
}
.bss :
{
*(.bss)
*(COMMON)
}
_dend = ABSOLUTE(.) ; /* end of code and data */
}
--------------------------------------------------------------------
and mips-elf-objdump -h a.out shows:
a.out: file format elf32-littlemips
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00001ab4 811ed000 811ed000 00001000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 0000004c 811eeab4 811eeab4 00002ab4 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000620 811eeb00 811eeb00 00002b00 2**3
ALLOC
3 .reginfo 00000018 00000000 00000000 00002b00 2**2
CONTENTS, READONLY, LINK_ONCE_SAME_SIZE
4 .pdr 000003c0 00000000 00000000 00002b18 2**2
CONTENTS, READONLY
5 .mdebug.abi32 00000000 00000000 00000000 00002ed8 2**0
CONTENTS, READONLY
The linker create a real '.bss' section in the output ELF file and
store some data inside the section, which greatly increase the size
of the ELF file.
How can I do to inform the linker don't produce any data for the .bss section?
My linker is:
mips-elf-ld -v
GNU ld version 2.15
BTW, I'd like to know how to get a minimal ELF file. As you see, the offset of the
first section is 0x1000, which means the size of the ELF header is 4K in bytes.
Is there a way to cut off the size of the header?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How to inform the linker not to produce any data for a .bss section?
2007-12-09 2:51 How to inform the linker not to produce any data for a .bss section? PRC
@ 2007-12-09 20:07 ` Daniel Jacobowitz
2007-12-11 1:19 ` Re: How to inform the linker not to produce any data for a .bsssection? PRC
0 siblings, 1 reply; 8+ messages in thread
From: Daniel Jacobowitz @ 2007-12-09 20:07 UTC (permalink / raw)
To: PRC; +Cc: binutils
On Sun, Dec 09, 2007 at 10:50:50AM +0800, PRC wrote:
> 2 .bss 00000620 811eeb00 811eeb00 00002b00 2**3
> ALLOC
> The linker create a real '.bss' section in the output ELF file and
> store some data inside the section, which greatly increase the size
> of the ELF file.
No, it didn't. It takes up no space in the file because it does not
have the CONTENTS flag.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: How to inform the linker not to produce any data for a .bsssection?
2007-12-09 20:07 ` Daniel Jacobowitz
@ 2007-12-11 1:19 ` PRC
2007-12-11 12:59 ` Daniel Jacobowitz
0 siblings, 1 reply; 8+ messages in thread
From: PRC @ 2007-12-11 1:19 UTC (permalink / raw)
To: Daniel Jacobowitz, pkoning; +Cc: binutils
There is a global static array in my code:
static char cmd_buffer[1024*64] __attribute__(( section(".mydata") ));
And inform the linker to put it in section ".bss":
.bss :
{
*(.bss)
*(COMMON)
*(.mydata)
}
mips-elf-objdump -h a.out
-------------------------------------------------------------------
3 .bss 00010620 81413898 81413898 00003898 2**3
ALLOC
4 .reginfo 00000018 00000000 00000000 00013eb8 2**2
CONTENTS, READONLY, LINK_ONCE_SAME_SIZE
------------------------------------------------------------------
The difference between sections ".bss" and ".reginfo" is almost 64K,
which is just the size of the buffer `cmd_buffer`. And I check the
output file, and find there are lots of zero starting from the offset
0x3898. It seems the linker puts 64K zeros in the section ".bss".
On Sun, Dec 09, 2007 at 10:50:50AM +0800, PRC wrote:
> 2 .bss 00000620 811eeb00 811eeb00 00002b00 2**3
> ALLOC
> The linker create a real '.bss' section in the output ELF file and
> store some data inside the section, which greatly increase the size
> of the ELF file.
No, it didn't. It takes up no space in the file because it does not
have the CONTENTS flag.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: How to inform the linker not to produce any data for a .bsssection?
2007-12-11 1:19 ` Re: How to inform the linker not to produce any data for a .bsssection? PRC
@ 2007-12-11 12:59 ` Daniel Jacobowitz
2007-12-12 9:08 ` Dave Murphy
2007-12-18 10:19 ` Re: Re: How to inform the linker not to produce any data for a.bsssection? PRC
0 siblings, 2 replies; 8+ messages in thread
From: Daniel Jacobowitz @ 2007-12-11 12:59 UTC (permalink / raw)
To: PRC; +Cc: pkoning, binutils
On Tue, Dec 11, 2007 at 09:19:12AM +0800, PRC wrote:
> mips-elf-objdump -h a.out
> -------------------------------------------------------------------
> 3 .bss 00010620 81413898 81413898 00003898 2**3
> ALLOC
> 4 .reginfo 00000018 00000000 00000000 00013eb8 2**2
> CONTENTS, READONLY, LINK_ONCE_SAME_SIZE
> ------------------------------------------------------------------
> The difference between sections ".bss" and ".reginfo" is almost 64K,
> which is just the size of the buffer `cmd_buffer`. And I check the
> output file, and find there are lots of zero starting from the offset
> 0x3898. It seems the linker puts 64K zeros in the section ".bss".
This is necessary alignment. If you don't want .bss to take up space
in the file, do not put allocated sections after it.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How to inform the linker not to produce any data for a .bsssection?
2007-12-11 12:59 ` Daniel Jacobowitz
@ 2007-12-12 9:08 ` Dave Murphy
2007-12-12 14:19 ` Daniel Jacobowitz
2007-12-18 10:19 ` Re: Re: How to inform the linker not to produce any data for a.bsssection? PRC
1 sibling, 1 reply; 8+ messages in thread
From: Dave Murphy @ 2007-12-12 9:08 UTC (permalink / raw)
To: binutils
Daniel Jacobowitz wrote:
> This is necessary alignment. If you don't want .bss to take up space
> in the file, do not put allocated sections after it.
>
Is there any way to change that behavior without causing problems?
I'm trying to regain a little extra memory for the heap on a newlib
based toolchain where the device binary starts in RAM. It's an arm946
with 48k of tcm.
I've tried placing .itcm & .dtcm sections after the .bss section which
causes it to consume space in the binary so I tried setting the VMA for
the bss to the LMA for the first preceeding section, like this
__dtcm_lma = . ;
.dtcm __dtcm_start : AT (__dtcm_lma)
{
*(.dtcm)
*(.dtcm.*)
. = ALIGN(4);
__dtcm_end = ABSOLUTE(.);
} >dtcm = 0xff
__itcm_lma = __dtcm_lma + SIZEOF(.dtcm);
.itcm __itcm_start : AT (__itcm_lma)
{
*(.itcm)
*itcm.*(.text)
. = ALIGN(4);
__itcm_end = ABSOLUTE(.);
} >itcm = 0xff
.sbss __dtcm_end :
{
__sbss_start = ABSOLUTE(.);
__sbss_start__ = ABSOLUTE(.);
*(.sbss)
. = ALIGN(4); /* REQUIRED. LD is flaky without it. */
__sbss_end = ABSOLUTE(.);
} >dtcm
__bss_lma = __itcm_lma + SIZEOF(.itcm) ;
__appended_data = __itcm_lma + SIZEOF(.itcm) ;
.bss __bss_lma : AT (__dtcm_lma)
{
__bss_start = ABSOLUTE(.);
__bss_start__ = ABSOLUTE(.);
*(.dynbss)
*(.gnu.linkonce.b*)
*(.bss*)
*(COMMON)
. = ALIGN(4); /* REQUIRED. LD is flaky without it. */
__bss_end = ABSOLUTE(.) ;
__bss_end__ = __bss_end ;
} >ewram
_end = . ;
__end__ = . ;
PROVIDE (end = _end);
ld errored with "section .bss [0200c5b8 -> 0200c647] overlaps section
.itcm [0200c5b8 -> 0200c747]" so I tried placing .bss first & setting
the LMA of the following section to the bss segment. That got me the
opposite error.
__dtcm_lma = . ;
__bss_start = .;
__bss_start__ = .;
.bss :
{
*(.dynbss)
*(.bss .bss.* .gnu.linkonce.b.*)
*(COMMON)
/* Align here to ensure that the .bss section occupies space up to
_end. Align after .bss to ensure correct alignment even if the
.bss section disappears because there are no input sections.
FIXME: Why do we need it? When there is no .bss section, we don't
pad the .data section. */
. = ALIGN(. != 0 ? 32 / 8 : 1);
} >ewram
__bss_end = . ; __bss_end__ = . ;
_end = . ;
__end__ = . ;
.dtcm __dtcm_start : AT (__dtcm_lma)
{
*(.dtcm)
*(.dtcm.*)
. = ALIGN(4);
__dtcm_end = ABSOLUTE(.);
} >dtcm
__itcm_lma = __dtcm_lma + SIZEOF(.dtcm);
.itcm __itcm_start : AT (__itcm_lma)
{
*(.itcm)
*itcm.*(.text)
. = ALIGN(4);
__itcm_end = ABSOLUTE(.);
} >itcm
Dave
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How to inform the linker not to produce any data for a .bsssection?
2007-12-12 9:08 ` Dave Murphy
@ 2007-12-12 14:19 ` Daniel Jacobowitz
0 siblings, 0 replies; 8+ messages in thread
From: Daniel Jacobowitz @ 2007-12-12 14:19 UTC (permalink / raw)
To: binutils
On Wed, Dec 12, 2007 at 09:08:15AM +0000, Dave Murphy wrote:
> Daniel Jacobowitz wrote:
> > This is necessary alignment. If you don't want .bss to take up space
> > in the file, do not put allocated sections after it.
> >
>
> Is there any way to change that behavior without causing problems?
Try manually defining PHDRs? If the bss section is the last thing in
its segment, it won't take extra load space.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: Re: How to inform the linker not to produce any data for a.bsssection?
2007-12-11 12:59 ` Daniel Jacobowitz
2007-12-12 9:08 ` Dave Murphy
@ 2007-12-18 10:19 ` PRC
2007-12-18 11:34 ` Ivan Pulleyn
1 sibling, 1 reply; 8+ messages in thread
From: PRC @ 2007-12-18 10:19 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: pkoning, binutils
Hi, Jacobowitz
Can you tell me how to modify the link script to prevent .bss taking up space in file?
I didn't grap your meanings and have no idea what to do.
On Tue, Dec 11, 2007 at 09:19:12AM +0800, PRC wrote:
> mips-elf-objdump -h a.out
> -------------------------------------------------------------------
> 3 .bss 00010620 81413898 81413898 00003898 2**3
> ALLOC
> 4 .reginfo 00000018 00000000 00000000 00013eb8 2**2
> CONTENTS, READONLY, LINK_ONCE_SAME_SIZE
> ------------------------------------------------------------------
> The difference between sections ".bss" and ".reginfo" is almost 64K,
> which is just the size of the buffer `cmd_buffer`. And I check the
> output file, and find there are lots of zero starting from the offset
> 0x3898. It seems the linker puts 64K zeros in the section ".bss".
This is necessary alignment. If you don't want .bss to take up space
in the file, do not put allocated sections after it.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: Re: How to inform the linker not to produce any data for a.bsssection?
2007-12-18 10:19 ` Re: Re: How to inform the linker not to produce any data for a.bsssection? PRC
@ 2007-12-18 11:34 ` Ivan Pulleyn
0 siblings, 0 replies; 8+ messages in thread
From: Ivan Pulleyn @ 2007-12-18 11:34 UTC (permalink / raw)
To: PRC; +Cc: Daniel Jacobowitz, pkoning, binutils
On Dec 18, 2007 2:18 AM, PRC <panruochen@gmail.com> wrote:
> Hi, Jacobowitz
>
> Can you tell me how to modify the link script to prevent .bss taking up space in file?
> I didn't grap your meanings and have no idea what to do.
If you define something at the end of the BSS, the linker is forced to
create it. I believe that if you (a) make sure BSS is defined at the
end of your linker script and (b) make sure nothing is inside that
section (get rid of the mydata thing) then BSS will not take up any
space on disk.
Ivan...
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-12-18 11:34 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-09 2:51 How to inform the linker not to produce any data for a .bss section? PRC
2007-12-09 20:07 ` Daniel Jacobowitz
2007-12-11 1:19 ` Re: How to inform the linker not to produce any data for a .bsssection? PRC
2007-12-11 12:59 ` Daniel Jacobowitz
2007-12-12 9:08 ` Dave Murphy
2007-12-12 14:19 ` Daniel Jacobowitz
2007-12-18 10:19 ` Re: Re: How to inform the linker not to produce any data for a.bsssection? PRC
2007-12-18 11:34 ` Ivan Pulleyn
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).