PATCH: put .sdata2/.sbss2 into the writable segment on vxworks ppc

PATCH: put .sdata2/.sbss2 into the writable segment on vxworks ppc

[Tristan Gingold]

Hi,

on VxWorks 6 (for powerpc) all the .sdata2 sections of the library  
are flagged RW.
Therefore during the final link (in RTP mode) the corresponding  
segment must be RW.
Currently these sections are always put into the RX segment by the  
linker script.  As a consequence
this segment becomes RWX which is unfortunate.

This patch fixes this issue by adding a new variable: WRITABLE_SDATA2.

Tristan.

ld:
2007-10-11  Tristan Gingold  <gingold@adacore.com>

	* scripttempl/elf.sc: If WRITABLE_SDATA2 is set, put .sdata2 and
	.sbss2 sections into the writable segment.

	* emulparams/elf32ppcvxworks.sh (WRITABLE_SDATA2): Defined.

*** ld/emulparams/elf32ppcvxworks.sh    2 Mar 2006 08:50:04  
-0000       1.2
--- ld/emulparams/elf32ppcvxworks.sh    23 Oct 2007 16:07:57 -0000
***************
*** 1,3 ****
--- 1,4 ----
   . ${srcdir}/emulparams/elf32ppccommon.sh
   OUTPUT_FORMAT="elf32-powerpc-vxworks"
+ WRITABLE_SDATA2=
   . ${srcdir}/emulparams/vxworks.sh


*** ld/scripttempl/elf.sc       27 Jul 2007 22:33:24 -0000      1.83
--- ld/scripttempl/elf.sc       23 Oct 2007 16:07:58 -0000
***************
*** 3,8 ****
--- 3,9 ----
   #     NOP - four byte opcode for no-op (defaults to 0)
   #     NO_SMALL_DATA - no .sbss/.sbss2/.sdata/.sdata2 sections if not
   #             empty.
+ #     WRITABLE_SDATA2 - if set, the .sdata2/.sbss2 sections should  
be writable
   #     SMALL_DATA_CTOR - .ctors contains small data.
   #     SMALL_DATA_DTOR - .dtors contains small data.
   #     DATA_ADDR - if end-of-text-plus-one-page isn't right for  
data start
***************
*** 366,373 ****
     ${RELOCATING+PROVIDE (${ETEXT_NAME} = .);}
     ${WRITABLE_RODATA-${RODATA}}
     .rodata1      ${RELOCATING-0} : { *(.rodata1) }
!   ${CREATE_SHLIB-${SDATA2}}
!   ${CREATE_SHLIB-${SBSS2}}
     ${OTHER_READONLY_SECTIONS}
     .eh_frame_hdr : { *(.eh_frame_hdr) }
     .eh_frame     ${RELOCATING-0} : ONLY_IF_RO { KEEP (*(.eh_frame)) }
--- 367,374 ----
     ${RELOCATING+PROVIDE (${ETEXT_NAME} = .);}
     ${WRITABLE_RODATA-${RODATA}}
     .rodata1      ${RELOCATING-0} : { *(.rodata1) }
!   ${CREATE_SHLIB-${WRITABLE_SDATA2-${SDATA2}}}
!   ${CREATE_SHLIB-${WRITABLE_SDATA2-${SBSS2}}}
     ${OTHER_READONLY_SECTIONS}
     .eh_frame_hdr : { *(.eh_frame_hdr) }
     .eh_frame     ${RELOCATING-0} : ONLY_IF_RO { KEEP (*(.eh_frame)) }
***************
*** 432,437 ****
--- 433,440 ----
     }
     .data1        ${RELOCATING-0} : { *(.data1) }
     ${WRITABLE_RODATA+${RODATA}}
+   ${CREATE_SHLIB-${WRITABLE_SDATA2+${SDATA2}}}
+   ${CREATE_SHLIB-${WRITABLE_SDATA2+${SBSS2}}}
     ${OTHER_READWRITE_SECTIONS}
     ${SMALL_DATA_CTOR+${RELOCATING+${CTOR}}}
     ${SMALL_DATA_DTOR+${RELOCATING+${DTOR}}}

Re: PATCH: put .sdata2/.sbss2 into the writable segment on vxworks ppc

[Alan Modra]

On Tue, Oct 23, 2007 at 06:13:00PM +0200, Tristan Gingold wrote:
> 	* scripttempl/elf.sc: If WRITABLE_SDATA2 is set, put .sdata2 and
> 	.sbss2 sections into the writable segment.
> 
> 	* emulparams/elf32ppcvxworks.sh (WRITABLE_SDATA2): Defined.

OK.

-- 
Alan Modra
Australia Development Lab, IBM

Re: PATCH: put .sdata2/.sbss2 into the writable segment on vxworks ppc

[Daniel Jacobowitz]

On Tue, Oct 23, 2007 at 06:13:00PM +0200, Tristan Gingold wrote:
> Hi,
> 
> on VxWorks 6 (for powerpc) all the .sdata2 sections of the library are flagged 
> RW.
> Therefore during the final link (in RTP mode) the corresponding segment must be 
> RW.
> Currently these sections are always put into the RX segment by the linker 
> script.  As a consequence
> this segment becomes RWX which is unfortunate.
> 
> This patch fixes this issue by adding a new variable: WRITABLE_SDATA2.

(FYI, CodeSourcery builds the official VxWorks toolchains.  We're
sometimes very good at keeping the FSF tree up to date, and sometimes
a bit behind...)

I know I've seen this problem before.  I don't remember the exact
details, but I believe there was a bit more wrong here dealing with
the VxWorks loader's restrictions on the number of segments in
executables.

Nathan, there's a more complete patch with your name on it from
2007-07-24; think you could post it and the followup?

-- 
Daniel Jacobowitz
CodeSourcery

Re: PATCH: put .sdata2/.sbss2 into the writable segment on vxworks ppc

[Tristan Gingold]

On Oct 24, 2007, at 4:23 AM, Daniel Jacobowitz wrote:

> (FYI, CodeSourcery builds the official VxWorks toolchains.
Yes I know :-)

>   We're
> sometimes very good at keeping the FSF tree up to date, and sometimes
> a bit behind...)
Ok.

> I know I've seen this problem before.  I don't remember the exact
> details, but I believe there was a bit more wrong here dealing with
> the VxWorks loader's restrictions on the number of segments in
> executables.

We have more patches to be submitted for vxworks:

* enable --gc-section with -r and -q: we think this is a very useful  
feature for vxworks.

* merge gc sections with -r: the patch is not yet ready to be  
submitted as I think it would be better to
   have a new flag.

Tristan.

Re: PATCH: put .sdata2/.sbss2 into the writable segment on vxworks ppc

[Tristan Gingold]

Hi Nathan and Daniel,

are you currently off ?  I'd like to read your patch (and see it in  
the FSF tree).

Tristan.

On Oct 24, 2007, at 4:23 AM, Daniel Jacobowitz wrote:

> On Tue, Oct 23, 2007 at 06:13:00PM +0200, Tristan Gingold wrote:
>> Hi,
>>
>> on VxWorks 6 (for powerpc) all the .sdata2 sections of the library  
>> are flagged
>> RW.
>> Therefore during the final link (in RTP mode) the corresponding  
>> segment must be
>> RW.
>> Currently these sections are always put into the RX segment by the  
>> linker
>> script.  As a consequence
>> this segment becomes RWX which is unfortunate.
>>
>> This patch fixes this issue by adding a new variable:  
>> WRITABLE_SDATA2.
>
> (FYI, CodeSourcery builds the official VxWorks toolchains.  We're
> sometimes very good at keeping the FSF tree up to date, and sometimes
> a bit behind...)
>
> I know I've seen this problem before.  I don't remember the exact
> details, but I believe there was a bit more wrong here dealing with
> the VxWorks loader's restrictions on the number of segments in
> executables.
>
> Nathan, there's a more complete patch with your name on it from
> 2007-07-24; think you could post it and the followup?
>
> -- 
> Daniel Jacobowitz
> CodeSourcery
>