* Comments requested for proposed for ld scripting language extension
@ 2011-04-28 16:48 Catherine Moore
2011-04-29 0:24 ` Alan Modra
2011-04-29 7:35 ` Tristan Gingold
0 siblings, 2 replies; 6+ messages in thread
From: Catherine Moore @ 2011-04-28 16:48 UTC (permalink / raw)
To: binutils, 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Comments requested for proposed for ld scripting language extension
2011-04-28 16:48 Comments requested for proposed for ld scripting language extension Catherine Moore
@ 2011-04-29 0:24 ` Alan Modra
2011-04-29 7:35 ` Tristan Gingold
1 sibling, 0 replies; 6+ messages in thread
From: Alan Modra @ 2011-04-29 0:24 UTC (permalink / raw)
To: Catherine Moore; +Cc: binutils
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Comments requested for proposed for ld scripting language extension
2011-04-28 16:48 Comments requested for proposed for ld scripting language extension Catherine Moore
2011-04-29 0:24 ` Alan Modra
@ 2011-04-29 7:35 ` Tristan Gingold
2011-05-03 8:44 ` Richard Sandiford
1 sibling, 1 reply; 6+ messages in thread
From: Tristan Gingold @ 2011-04-29 7:35 UTC (permalink / raw)
To: Catherine Moore; +Cc: binutils
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Comments requested for proposed for ld scripting language extension
2011-04-29 7:35 ` Tristan Gingold
@ 2011-05-03 8:44 ` Richard Sandiford
2011-05-03 8:52 ` Tristan Gingold
2011-05-03 14:35 ` Catherine Moore
0 siblings, 2 replies; 6+ messages in thread
From: Richard Sandiford @ 2011-05-03 8:44 UTC (permalink / raw)
To: Tristan Gingold; +Cc: Catherine Moore, binutils
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Comments requested for proposed for ld scripting language extension
2011-05-03 8:44 ` Richard Sandiford
@ 2011-05-03 8:52 ` Tristan Gingold
2011-05-03 14:35 ` Catherine Moore
1 sibling, 0 replies; 6+ messages in thread
From: Tristan Gingold @ 2011-05-03 8:52 UTC (permalink / raw)
To: Richard Sandiford; +Cc: Catherine Moore, binutils
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Comments requested for proposed for ld scripting language extension
2011-05-03 8:44 ` Richard Sandiford
2011-05-03 8:52 ` Tristan Gingold
@ 2011-05-03 14:35 ` Catherine Moore
1 sibling, 0 replies; 6+ messages in thread
From: Catherine Moore @ 2011-05-03 14:35 UTC (permalink / raw)
To: Tristan Gingold, binutils, richard.sandiford, amodra
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-05-03 14:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-28 16:48 Comments requested for proposed for ld scripting language extension Catherine Moore
2011-04-29 0:24 ` Alan Modra
2011-04-29 7:35 ` Tristan Gingold
2011-05-03 8:44 ` Richard Sandiford
2011-05-03 8:52 ` Tristan Gingold
2011-05-03 14:35 ` Catherine Moore
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).