Comments requested for proposed for ld scripting language extension

Comments requested for proposed for ld scripting language extension

[Catherine Moore]

I've been working on a binutils port to the Freescale VLE part, more 
specifically, on interlinking.  For those not familiar with the 
requirements, interlinking is a bit different than for other ports such 
as ARM and MIPS.  There are no special call instructions or mode 
switches.  BookE and VLE instructions can be intermixed as long as they 
reside in separate ELF sections.  The VLE instruction sections are 
marked with a PowerPC-specific section header (SHF_PPC_VLE).

Because we have so many "specially named" sections .gnu.linkonce, .text, 
.init, and friends, I want to avoid a scheme that relies on a naming 
convention to differentiate between VLE sections and BookE sections. 
What I would like to do is add an extension to the scripting language. 
Something like this:

MEMORY
{
   ram (rwx) : ORIGIN = 0x100000, LENGTH = 144M
}

SECTIONS
{
   .text : WITHOUT_FLAGS (SHF_PPC_VLE)
   {
     *(.text .text.* .gnu.linkonce.t.*)
   } >ram
   .text_vle : WITH_FLAGS (SHF_PPC_VLE)
   {
     *(.text .text.* .gnu.linkonce.t.*)
   } >ram
}

map_input_to_output_sections would then walk the input sections for 
those sections with an optional "FLAG" marker.  A callback would be 
introduced that would examine the ELF header flags for the input 
sections and gather only those that met the criteria.

I realize that this is an ELF-centric proposal.  Although it could be 
extended to include other object formats, I haven't given that aspect 
alot of thought.

Before I spend time on development, I'd like to solicit comments ahead 
of time.  How do the maintainers and others feel about this plan?

Thanks,
Catherine

Re: Comments requested for proposed for ld scripting language extension

[Alan Modra]

On Thu, Apr 28, 2011 at 12:47:52PM -0400, Catherine Moore wrote:
> How do the maintainers and others feel about this plan?

Sounds a reasonable extension of the existing constraint (ONLY_IF_RW,
ONLY_IF_RO, SPECIAL) handling.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Comments requested for proposed for ld scripting language extension

[Tristan Gingold]

On Apr 28, 2011, at 6:47 PM, Catherine Moore wrote:

[...]

> What I would like to do is add an extension to the scripting language. Something like this:
> 
> MEMORY
> {
>  ram (rwx) : ORIGIN = 0x100000, LENGTH = 144M
> }
> 
> SECTIONS
> {
>  .text : WITHOUT_FLAGS (SHF_PPC_VLE)
>  {
>    *(.text .text.* .gnu.linkonce.t.*)
>  } >ram
>  .text_vle : WITH_FLAGS (SHF_PPC_VLE)
>  {
>    *(.text .text.* .gnu.linkonce.t.*)
>  } >ram
> }
> 
> map_input_to_output_sections would then walk the input sections for those sections with an optional "FLAG" marker.  A callback would be introduced that would examine the ELF header flags for the input sections and gather only those that met the criteria.
> 
> I realize that this is an ELF-centric proposal.  Although it could be extended to include other object formats, I haven't given that aspect alot of thought.
> 
> Before I spend time on development, I'd like to solicit comments ahead of time.  How do the maintainers and others feel about this plan?

I had similar thoughts but for the VMS format, where the section names are less important than their flags.

I think your proposal isn't that ELF-centric: the flags could be a mix of bfd ones (either from section or from file) and target
specific ones.

I also think that you could make the design a little bit generic and allow boolean negation.  What about something like:

 .text : FLAGS (-SHF_PPC_VLE)
 {
   *(.text .text.* .gnu.linkonce.t.*)
 } >ram
 .text_vle : FLAGS (+SHF_PPC_VLE)
 {
   *(.text .text.* .gnu.linkonce.t.*)
 } >ram

That would make the life easier if we later want to add boolean operators (and, or).


Finally I wonder if the flags shouldn't be in the input section part, in order to make this feature even more generic:

.text : 
 {
   *(.text .text.* .gnu.linkonce.t.*) FLAGS (-SHF_PPC_VLE)
 } >ram
 
Tristan.

Re: Comments requested for proposed for ld scripting language extension

[Richard Sandiford]

Tristan Gingold <gingold@adacore.com> writes:
> I also think that you could make the design a little bit generic and
> allow boolean negation.  What about something like:

Sounds good, but...

>
>  .text : FLAGS (-SHF_PPC_VLE)
>  {
>    *(.text .text.* .gnu.linkonce.t.*)
>  } >ram
>  .text_vle : FLAGS (+SHF_PPC_VLE)
>  {
>    *(.text .text.* .gnu.linkonce.t.*)
>  } >ram

...how about using C operators (SHF_PPC_VLE and !SHF_PPC_VLE) instead?
That'd be more consistent with other script expressions.

> Finally I wonder if the flags shouldn't be in the input section part,
> in order to make this feature even more generic:
>
> .text : 
>  {
>    *(.text .text.* .gnu.linkonce.t.*) FLAGS (-SHF_PPC_VLE)
>  } >ram

While this might be useful in some cases, I think Catherine's version
is going to make the usual case easier.  FWIW, I agree with Alan that
it fits nicely with the existing ONLY_IF_* constraints.

Richard

Re: Comments requested for proposed for ld scripting language extension

[Tristan Gingold]

On May 3, 2011, at 10:44 AM, Richard Sandiford wrote:

> Tristan Gingold <gingold@adacore.com> writes:
>> I also think that you could make the design a little bit generic and
>> allow boolean negation.  What about something like:
> 
> Sounds good, but...
> 
>> 
>> .text : FLAGS (-SHF_PPC_VLE)
>> {
>>   *(.text .text.* .gnu.linkonce.t.*)
>> } >ram
>> .text_vle : FLAGS (+SHF_PPC_VLE)
>> {
>>   *(.text .text.* .gnu.linkonce.t.*)
>> } >ram
> 
> ...how about using C operators (SHF_PPC_VLE and !SHF_PPC_VLE) instead?
> That'd be more consistent with other script expressions.

Sure.

>> Finally I wonder if the flags shouldn't be in the input section part,
>> in order to make this feature even more generic:
>> 
>> .text : 
>> {
>>   *(.text .text.* .gnu.linkonce.t.*) FLAGS (-SHF_PPC_VLE)
>> } >ram
> 
> While this might be useful in some cases, I think Catherine's version
> is going to make the usual case easier.  FWIW, I agree with Alan that
> it fits nicely with the existing ONLY_IF_* constraints.
> 
> Richard

Re: Comments requested for proposed for ld scripting language extension

[Catherine Moore]

On 05/03/2011 04:44 AM, Richard Sandiford wrote:
> Tristan Gingold<gingold@adacore.com>  writes:
>> I also think that you could make the design a little bit generic and
>> allow boolean negation.  What about something like:
>
> Sounds good, but...
>
>>
>>   .text : FLAGS (-SHF_PPC_VLE)
>>   {
>>     *(.text .text.* .gnu.linkonce.t.*)
>>   }>ram
>>   .text_vle : FLAGS (+SHF_PPC_VLE)
>>   {
>>     *(.text .text.* .gnu.linkonce.t.*)
>>   }>ram
>
> ...how about using C operators (SHF_PPC_VLE and !SHF_PPC_VLE) instead?
> That'd be more consistent with other script expressions.
>

Thank you all for the comments.  I will plan to implement this version 
using C operators.

>> Finally I wonder if the flags shouldn't be in the input section part,
>> in order to make this feature even more generic:
>>
>> .text :
>>   {
>>     *(.text .text.* .gnu.linkonce.t.*) FLAGS (-SHF_PPC_VLE)
>>   }>ram
>
> While this might be useful in some cases, I think Catherine's version
> is going to make the usual case easier.  FWIW, I agree with Alan that
> it fits nicely with the existing ONLY_IF_* constraints.
>

Catherine