This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Common sections
It's ELF64 and the target ressembles MIPS.
I put in my script file something like:
. = 0x20000;
.data_small : { *(.data_small) }
.lbss_small : { *(.lbss_small) }
.bss_small : { *(.bss_small) }
. = 0x200000;
.text_big : { *(.text_big) }
.data_big : { *(.data_big) }
.sbss_big : { *(.sbss_big) }
.lbss_big : { *(.lbss_big) }
.bss_big : { *(.bss_big) }
...
.sbss :
{
*(.dynsbss)
*(.sbss .sbss.* .gnu.linkonce.sb.*)
*(.scommon)
}
.bss :
{
*(.dynbss)
*(.bss .bss.* .gnu.linkonce.b.*)
*(COMMON)
}
If I modify the code so that the elements are sent in :
bss, sbss : no problem, everything is fine
bss_big : they overlap
bss_small: they overlap
Theoretically, I don't automatically want them to be COMMON, I'd just
like the addressing to be done right.
Is it possible that because of the way the script is written, it takes
the same address per file because of that ?
Thanks again,
Jc
On Mon, Jun 7, 2010 at 11:00 AM, Ian Lance Taylor <iant@google.com> wrote:
> fearyourself <fearyourself@gmail.com> writes:
>
>> Basically, I have a segment called bss_big which is the big memory
>> segment. If I compile two .c files such as :
>>
>> fct1.c:
>>
>> long target;
>> long targeta;
>>
>> fct2.c:
>>
>> long target2;
>> long target2a;
>>
>> then I get the same address for target and target2. And the same
>> address for targeta and target2a.
>
> That sounds like a rather serious bug. ?What object file format are
> you using? ?What target?
>
>> Were I to put this section as SEC_IS_COMMON, it works well and
>> actually puts the addresses right but then it fails on the archives
>> problem where if I do :
>
> That is the opposite of what I would expect. ?If the section is not
> SEC_IS_COMMON, I don't see how the linker could cause it to overlap
> like that. ?It seems more possible of the section is SEC_IS_COMMON,
> although even then I don't see how it could happen.
>
> If you search for SHN_X86_64_LCOMMON in bfd/elf64-x86-64.c you will
> see one way of handling large common symbols.
>
> Ian
>