[PATCH] Large section data, was: [PATCH] Updated RDOS support

Wed Jan 9 20:12:00 GMT 2013

I've created a specific patch for large section data and provide it 
separately since it is not directly related to rdos.

Change log (ld directory):
* scripttempl/elf.sc (LARGE_BSS): Define rather than appending to 
OTHER_BSS_SECTIONS.  Add support for LARGE_DATA_ADDR and position of lbss 
(LARGE_BSS_LAST_IN_LARGE_DATA).
* ldlex.h: Define ldata-segment option.
* lexsup.c: Process ldata-segment option.
* ld.texinfo: Describe ldata-segment parameter.
* ld.1: Regenerate.
* ld.info: Regenerate.

Tested with and without LARGE_BSS_LAST_IN_LARGE_DATA, and with address 
override for ldata-segment on target rdos.

Leif Ekblad

----- Original Message ----- 
From: "Alan Modra" <amodra@gmail.com>
To: "Leif Ekblad" <leif@rdos.net>
Cc: <binutils@sourceware.org>
Sent: Wednesday, January 09, 2013 6:51 AM
Subject: Re: [PATCH] Updated RDOS support

> On Tue, Jan 08, 2013 at 09:43:16PM +0100, Leif Ekblad wrote:
>>
>> ----- Original Message ----- From: "Alan Modra" <amodra@gmail.com>
>> >Why should $LARGE_DATA_ADDR affect $OTHER_BSS_SECTIONS?  Hmm, I see
>> >LARGE_SECTIONS=yes adds .lbss to OTHER_BSS_SECTIONS.  That's not very
>> >nice as quite a few targets use OTHER_BSS_SECTIONS for other purposes.
>> >Your patch makes this even more confusing.  Also, since you seem to
>> >want a separate large segment, do you really want to lay out your
>> >large sections as .lbss, .lrodata, .ldata?  Wouldn't .lrodata, .ldata,
>> >.lbss make more sense?
>>
>> Yes, absolutely. If the lbss area is large it will also increase
>> executable size for no reason.
>> But, shouldn't this be the order regardless of LARGE_DATA_ADDR setting? 
>> This
>> seems like a bug.
>>
>> Thoughts?
>
> I don't know why the existing scripts put .lbss first.  The patch
> adding x86_64 support for large sections is here:
> http://sourceware.org/ml/binutils/2005-07/msg00407.html
> Prior to that, hppa64 had a huge bss section placed more or less in
> the same location but no large data or rodata section as far as I
> know.
>
> Here's a tidy that should make adding LARGE_DATA_ADDR easy.
>
> * emulparams/elf_x86_64.sh (LARGE_BSS_AFTER_BSS): Define.
> * emulparams/elf32_x86_64.sh: Likewise.
> * emulparams/elf_k1om.sh: Likewise.
> * emulparams/elf_l1om.sh: Likewise.
> * scripttempl/elf.sc (LARGE_BSS): Define rather than appending to
> OTHER_BSS_SECTIONS.  Substitute in script.
>
>> >Also, there isn't much point in adding support for -Tldata-segment
>> >here without the rest of the support, so that needs adding or simply
>> >omit use of SEGMENT_START().
>>
>> I think that if the large segment is separated by some TBs of
>> virtual memory,
>> the executable file would become enormous without a new section. But
>> I might be wrong here.
>
> You'll get a new segment (program header) whether or not SEGMENT_START
> is used.  See bfd/elf.c:_bfd_elf_map_sections_to_segments.  I'll leave
> answering your concern about SEPARATE_CODE to Roland.
>
>
> Index: ld/emulparams/elf32_x86_64.sh
> ===================================================================
> RCS file: /cvs/src/src/ld/emulparams/elf32_x86_64.sh,v
> retrieving revision 1.5
> diff -u -p -r1.5 elf32_x86_64.sh
> --- ld/emulparams/elf32_x86_64.sh 11 Jun 2012 13:23:50 -0000 1.5
> +++ ld/emulparams/elf32_x86_64.sh 9 Jan 2013 03:51:27 -0000
> @@ -13,6 +13,7 @@ GENERATE_SHLIB_SCRIPT=yes
> GENERATE_PIE_SCRIPT=yes
> NO_SMALL_DATA=yes
> LARGE_SECTIONS=yes
> +LARGE_BSS_AFTER_BSS=
> SEPARATE_GOTPLT="SIZEOF (.got.plt) >= 24 ? 24 : 0"
> IREL_IN_PLT=
>
> Index: ld/emulparams/elf_k1om.sh
> ===================================================================
> RCS file: /cvs/src/src/ld/emulparams/elf_k1om.sh,v
> retrieving revision 1.3
> diff -u -p -r1.3 elf_k1om.sh
> --- ld/emulparams/elf_k1om.sh 11 Jun 2012 13:23:50 -0000 1.3
> +++ ld/emulparams/elf_k1om.sh 9 Jan 2013 03:51:27 -0000
> @@ -14,6 +14,7 @@ GENERATE_SHLIB_SCRIPT=yes
> GENERATE_PIE_SCRIPT=yes
> NO_SMALL_DATA=yes
> LARGE_SECTIONS=yes
> +LARGE_BSS_AFTER_BSS=
> SEPARATE_GOTPLT="SIZEOF (.got.plt) >= 24 ? 24 : 0"
>
> if [ "x${host}" = "x${target}" ]; then
> Index: ld/emulparams/elf_l1om.sh
> ===================================================================
> RCS file: /cvs/src/src/ld/emulparams/elf_l1om.sh,v
> retrieving revision 1.5
> diff -u -p -r1.5 elf_l1om.sh
> --- ld/emulparams/elf_l1om.sh 11 Jun 2012 13:23:50 -0000 1.5
> +++ ld/emulparams/elf_l1om.sh 9 Jan 2013 03:51:27 -0000
> @@ -14,6 +14,7 @@ GENERATE_SHLIB_SCRIPT=yes
> GENERATE_PIE_SCRIPT=yes
> NO_SMALL_DATA=yes
> LARGE_SECTIONS=yes
> +LARGE_BSS_AFTER_BSS=
> SEPARATE_GOTPLT="SIZEOF (.got.plt) >= 24 ? 24 : 0"
>
> if [ "x${host}" = "x${target}" ]; then
> Index: ld/emulparams/elf_x86_64.sh
> ===================================================================
> RCS file: /cvs/src/src/ld/emulparams/elf_x86_64.sh,v
> retrieving revision 1.25
> diff -u -p -r1.25 elf_x86_64.sh
> --- ld/emulparams/elf_x86_64.sh 11 Jun 2012 13:23:50 -0000 1.25
> +++ ld/emulparams/elf_x86_64.sh 9 Jan 2013 03:51:27 -0000
> @@ -13,6 +13,7 @@ GENERATE_SHLIB_SCRIPT=yes
> GENERATE_PIE_SCRIPT=yes
> NO_SMALL_DATA=yes
> LARGE_SECTIONS=yes
> +LARGE_BSS_AFTER_BSS=
> SEPARATE_GOTPLT="SIZEOF (.got.plt) >= 24 ? 24 : 0"
> IREL_IN_PLT=
>
> Index: ld/scripttempl/elf.sc
> ===================================================================
> RCS file: /cvs/src/src/ld/scripttempl/elf.sc,v
> retrieving revision 1.117
> diff -u -p -r1.117 elf.sc
> --- ld/scripttempl/elf.sc 8 Jan 2013 09:23:07 -0000 1.117
> +++ ld/scripttempl/elf.sc 9 Jan 2013 03:51:27 -0000
> @@ -213,8 +213,7 @@ test "${LARGE_SECTIONS}" = "yes" && REL_
>   .rela.lbss    ${RELOCATING-0} : { *(.rela.lbss${RELOCATING+ .rela.lbss.* 
> .rela.gnu.linkonce.lb.*}) }
>   .rel.lrodata  ${RELOCATING-0} : { *(.rel.lrodata${RELOCATING+ 
> .rel.lrodata.* .rel.gnu.linkonce.lr.*}) }
>   .rela.lrodata ${RELOCATING-0} : { *(.rela.lrodata${RELOCATING+ 
> .rela.lrodata.* .rela.gnu.linkonce.lr.*}) }"
> -test "${LARGE_SECTIONS}" = "yes" && OTHER_BSS_SECTIONS="
> -  ${OTHER_BSS_SECTIONS}
> +test "${LARGE_SECTIONS}" = "yes" && LARGE_BSS="
>   .lbss ${RELOCATING-0} :
>   {
>     *(.dynlbss)
> @@ -606,9 +605,11 @@ cat <<EOF
>    ${RELOCATING+. = ALIGN(. != 0 ? ${ALIGNMENT} : 1);}
>   }
>   ${OTHER_BSS_SECTIONS}
> +  ${LARGE_BSS_AFTER_BSS+${LARGE_BSS}}
>   ${RELOCATING+${OTHER_BSS_END_SYMBOLS}}
>   ${RELOCATING+. = ALIGN(${ALIGNMENT});}
>   ${LARGE_SECTIONS}
> +  ${LARGE_BSS_AFTER_BSS-${LARGE_BSS}}
>   ${RELOCATING+. = ALIGN(${ALIGNMENT});}
>   ${RELOCATING+${OTHER_END_SYMBOLS}}
>   ${RELOCATING+${END_SYMBOLS-${USER_LABEL_PREFIX}_end = .; PROVIDE 
> (${USER_LABEL_PREFIX}end = .);}}
>
> -- 
> Alan Modra
> Australia Development Lab, IBM 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binutils.diff
Type: application/octet-stream
Size: 6080 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20130109/51bf5567/attachment.obj>