RFC: Sort input section by list

RFC: Sort input section by list

[H.J. Lu]

Hi,

I got a request for a new linker feature to sort input sections by a
list provided
at command line. I am investigating the following approach:

1. Change --sort-section to accept a linker script with a list of sections.
2. The linker script is similar to version script

.text {
  extern "C++"
  {
    foo(int);
  };
};

where .text will be the prefix of section name. It will match .text._Z3fooi.
3. Linker will insert .text._Z3fooi before ".text.*" in linker script, to turn

.text           :
{
    *(.text .stub .text.* .gnu.linkonce.t.*)
}

into

.text           :
{
    *(.text .stub .text._Z3fooi. .text.* .gnu.linkonce.t.*)
}
4. Multiple  --sort-section will be supported.

Any comments?

Thanks.


-- 
H.J.

Re: RFC: Sort input section by list

[Nick Clifton]

Hi H.J.

> I got a request for a new linker feature to sort input sections by a
> list provided at command line.

Is there a good reason for providing this list via a command line switch 
as opposed to say using a suitably customised linker script ?  (Possibly 
with an extended grammar for input section selection).

> 2. The linker script is similar to version script
> 
> .text {
>   extern "C++"
>   {
>     foo(int);
>   };
> };
> 
> where .text will be the prefix of section name. It will match .text._Z3fooi.

What is the real purpose of this feature ?  Ie do you know why it has 
been requested ?  The implication of the example you have given is that 
the user wants to put certain name-mangled functions at the start of the 
.text section, but why ?

(I suspect that the user's problem could be solved without modifying the 
linker by using gcc's "section" function attribute instead...)

> Any comments?

How do you specify that the named section is intended to go *after* the 
other sections that start with the same prefix ?

Cheers
   Nick

Re: RFC: Sort input section by list

[Arjan van de Ven]

Nick Clifton wrote:
> Hi H.J.
> 
>> I got a request for a new linker feature to sort input sections by a
>> list provided at command line.
> 
> Is there a good reason for providing this list via a command line switch 
> as opposed to say using a suitably customised linker script ?  (Possibly 
> with an extended grammar for input section selection).

a customized linker script depends on which exact gcc is used.
it's also effectively impossible to use in an autoconf/automake/libtool world.

While just putting in a file with a list of names is a ton easier for the upstream or
package developer.... while just keeping all the rest of linker scripts and compiler interactions as is.

> 
>> 2. The linker script is similar to version script
>>
>> .text {
>>   extern "C++"
>>   {
>>     foo(int);
>>   };
>> };
>>
>> where .text will be the prefix of section name. It will match 
>> .text._Z3fooi.
> 
> What is the real purpose of this feature ?  Ie do you know why it has 
> been requested ?  The implication of the example you have given is that 
> the user wants to put certain name-mangled functions at the start of the 
> .text section, but why ?

because it allows the developer to put the commonly used functions at the start of the file,
improving density in the page cache for example, and generally improving startup time.
(less pagefaults and less TLB pressure)

Re: RFC: Sort input section by list

[Nick Clifton]

Hi Arjan,

> a customized linker script depends on which exact gcc is used.
> it's also effectively impossible to use in an autoconf/automake/libtool 
> world.
> 
> While just putting in a file with a list of names is a ton easier for 
> the upstream or package developer.... while just keeping all the rest
 > of linker scripts and compiler interactions as is.

But a linker script fragment would be OK, right ?  (Since this 
essentially what HJ is proposing).

>> What is the real purpose of this feature ?  Ie do you know why it has 
>> been requested ?  The implication of the example you have given is 
>> that the user wants to put certain name-mangled functions at the start 
>> of the .text section, but why ?
> 
> because it allows the developer to put the commonly used functions at 
> the start of the file, improving density in the page cache for example, 
 > and generally improving  startup time. (less pagefaults and less
> TLB pressure)

But surely this could be done with gcc's section name function attribute 
without requiring any alterations to the linker ?

Cheers
   Nick

Re: RFC: Sort input section by list

[Arjan van de Ven]

Nick Clifton wrote:
>> because it allows the developer to put the commonly used functions at 
>> the start of the file, improving density in the page cache for example, 
>  > and generally improving  startup time. (less pagefaults and less
>> TLB pressure)
> 
> But surely this could be done with gcc's section name function attribute 
> without requiring any alterations to the linker ?
>
patching 3000 lines+ for each program ....
... versus running a profile and generating an automated list to feed the linker?

I know which one is usable in practice ;-)

Re: RFC: Sort input section by list

[Nick Clifton]

Hi Arjan,

>>> because it allows the developer to put the commonly used functions at 
>>> the start of the file, improving density in the page cache for example, 
>>  > and generally improving  startup time.

>> But surely this could be done with gcc's section name function 
>> attribute without requiring any alterations to the linker ?

> patching 3000 lines+ for each program ....
> ... versus running a profile and generating an automated list to feed 
> the linker?
> 
> I know which one is usable in practice ;-)

A generic method which will work with currently installed versions of 
gcc and the linker on most linux boxes...
...versus a new, untested feature in the linker, in a version of the 
linker that has not even been released yet.

I know which one I would choose. ;-)

Cheers
   Nick

Re: RFC: Sort input section by list

[Arjan van de Ven]

Nick Clifton wrote:
> Hi Arjan,
> 
>>>> because it allows the developer to put the commonly used functions 
>>>> at the start of the file, improving density in the page cache for 
>>>> example, 
>>>  > and generally improving  startup time.
> 
>>> But surely this could be done with gcc's section name function 
>>> attribute without requiring any alterations to the linker ?
> 
>> patching 3000 lines+ for each program ....
>> ... versus running a profile and generating an automated list to feed 
>> the linker?
>>
>> I know which one is usable in practice ;-)
> 
> A generic method which will work with currently installed versions of 
> gcc and the linker on most linux boxes...
> ...versus a new, untested feature in the linker, in a version of the 
> linker that has not even been released yet.
> 
> I know which one I would choose. ;-)

I suppose we chose differently; from a distro point of view patching each app's code that big
is a no go for us; once the new binutils is released we can automate and use the new feature
pretty quickly.
Add to this that which functions are on the list will also depend on which arguments you pass to configure...
sorry but really the "just patch the code in 3000 places" is really not going to work ;-(

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:07 AM, Nick Clifton <nickc@redhat.com> wrote:
>
> A generic method which will work with currently installed versions of gcc
> and the linker on most linux boxes...
> ...versus a new, untested feature in the linker, in a version of the linker
> that has not even been released yet.
>

All linker features were new, untested at one time. It shouldn't be
the reason not to implement/experiment them.


-- 
H.J.

Re: RFC: Sort input section by list

[Nick Clifton]

Hi H.J.

>> A generic method which will work with currently installed versions of gcc
>> and the linker on most linux boxes...
>> ...versus a new, untested feature in the linker, in a version of the linker
>> that has not even been released yet.

> All linker features were new, untested at one time. It shouldn't be
> the reason not to implement/experiment them.

True - but I am trying to avoid feature bloat here.  I do not want to 
add a new feature to solve a problem that can already be solved using 
existing methods.

Cheers
   Nick

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:07 AM, Nick Clifton <nickc@redhat.com> wrote:
>
> A generic method which will work with currently installed versions of gcc
> and the linker on most linux boxes...
> ...versus a new, untested feature in the linker, in a version of the linker
> that has not even been released yet.
>

All linker features were new, untested at one time. It shouldn't be
the reason not to implement/experiment them.


-- 
H.J.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:19 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi H.J.
>
>>> A generic method which will work with currently installed versions of gcc
>>> and the linker on most linux boxes...
>>> ...versus a new, untested feature in the linker, in a version of the
>>> linker
>>> that has not even been released yet.
>
>> All linker features were new, untested at one time. It shouldn't be
>> the reason not to implement/experiment them.
>
> True - but I am trying to avoid feature bloat here.  I do not want to add a
> new feature to solve a problem that can already be solved using existing
> methods.
>

As Arjan mentioned, it isn't practical to change so many packages to add
section attribute. It doesn't scale with number of packages nor updates
on packages.

-- 
H.J.

Re: RFC: Sort input section by list

[Christophe LYON]

>> What is the real purpose of this feature ?  Ie do you know why it has 
>> been requested ?  The implication of the example you have given is 
>> that the user wants to put certain name-mangled functions at the start 
>> of the .text section, but why ?
> 
> because it allows the developer to put the commonly used functions at 
> the start of the file,
> improving density in the page cache for example, and generally improving 
> startup time.
> (less pagefaults and less TLB pressure)
> 

Why not have a tool dedicated to this kind of optimization?
For one of our targets, we have developed a post linker tool which 
reorders functions based on call graph analysis.

The compiler driver asks the linker to keep all the relocations in the 
generated executable, and then calls the optimizer, which parses the ELF 
file and optionally a "layout file" to reorder code. By default it is 
used to improve locality (we have a direct mapped cache) based on static 
analysis, but can take advantage of profiling, or the user can even 
force the function order.

If the purpose is really to reorder functions, why should the developer 
need to deal with sections? (I mean, not all developers master the 
concept of section, do they?)


Christophe.

Re: RFC: Sort input section by list

[Eric Christopher]

On Aug 26, 2008, at 9:30 AM, H.J. Lu wrote:

> On Tue, Aug 26, 2008 at 9:19 AM, Nick Clifton <nickc@redhat.com>  
> wrote:
>> Hi H.J.
>>
>>>> A generic method which will work with currently installed  
>>>> versions of gcc
>>>> and the linker on most linux boxes...
>>>> ...versus a new, untested feature in the linker, in a version of  
>>>> the
>>>> linker
>>>> that has not even been released yet.
>>
>>> All linker features were new, untested at one time. It shouldn't be
>>> the reason not to implement/experiment them.
>>
>> True - but I am trying to avoid feature bloat here.  I do not want  
>> to add a
>> new feature to solve a problem that can already be solved using  
>> existing
>> methods.
>>
>
> As Arjan mentioned, it isn't practical to change so many packages to  
> add
> section attribute. It doesn't scale with number of packages nor  
> updates
> on packages.

FWIW it's a common feature type in a few linkers and quite handy for  
individual
app owners to use...

-eric

Re: RFC: Sort input section by list

[Nick Clifton]

Hi Arjan,

> I suppose we chose differently; from a distro point of view patching 
> each app's code that big
> is a no go for us; once the new binutils is released we can automate and 
> use the new feature
> pretty quickly.
> Add to this that which functions are on the list will also depend on 
> which arguments you pass to configure...
> sorry but really the "just patch the code in 3000 places" is really not 
> going to work ;-(

Would you agree that if a using-currently-available-tools process could 
be automated then it would be an acceptable solution to you ?

Lets assume that you have gotten to the stage where you have the 
profiled list of functions in the order you wish them to appear in the 
final binary.  Lets also assume that you have compiled the sources with 
-ffunction-sections.  You could use a sed/awk script to convert the 
function names into a linker script fragment that specifically 
references each of the function sections by name. Then all you would 
need is a slightly modified default linker script that INCLUDEs this 
constructed fragment at the right place in the generic linker script.

Cheers
   Nick

PS.  For the record I am not saying that this feature cannot be added to 
the linker.  I am just trying to avoid feature bloat by seeing if your 
problem can be solved by using the already existing features of the 
compiler and linker.

Re: RFC: Sort input section by list

[Arjan van de Ven]

Christophe LYON wrote:
> 
>>> What is the real purpose of this feature ?  Ie do you know why it has 
>>> been requested ?  The implication of the example you have given is 
>>> that the user wants to put certain name-mangled functions at the 
>>> start of the .text section, but why ?
>>
>> because it allows the developer to put the commonly used functions at 
>> the start of the file,
>> improving density in the page cache for example, and generally 
>> improving startup time.
>> (less pagefaults and less TLB pressure)
>>
> 
> Why not have a tool dedicated to this kind of optimization?
> For one of our targets, we have developed a post linker tool which 
> reorders functions based on call graph analysis.

cool! is this downloadable somewhere ? ;)
> 
> The compiler driver asks the linker to keep all the relocations in the 
> generated executable, and then calls the optimizer, which parses the ELF 
> file and optionally a "layout file" to reorder code. By default it is 
> used to improve locality (we have a direct mapped cache) based on static 
> analysis, but can take advantage of profiling, or the user can even 
> force the function order.
> 
> If the purpose is really to reorder functions, why should the developer 
> need to deal with sections? (I mean, not all developers master the 
> concept of section, do they?)

this is what -ffunction-sections is for

there are some complications like.. does the linker know what the end of a function is?
With tail packing but without sections.. I kind of fear the answer to be "no" ;(

Re: RFC: Sort input section by list

[Christophe LYON]

>> What is the real purpose of this feature ?  Ie do you know why it has 
>> been requested ?  The implication of the example you have given is 
>> that the user wants to put certain name-mangled functions at the start 
>> of the .text section, but why ?
> 
> because it allows the developer to put the commonly used functions at 
> the start of the file,
> improving density in the page cache for example, and generally improving 
> startup time.
> (less pagefaults and less TLB pressure)
> 

Why not have a tool dedicated to this kind of optimization?
For one of our targets, we have developed a post linker tool which 
reorders functions based on call graph analysis.

The compiler driver asks the linker to keep all the relocations in the 
generated executable, and then calls the optimizer, which parses the ELF 
file and optionally a "layout file" to reorder code. By default it is 
used to improve locality (we have a direct mapped cache) based on static 
analysis, but can take advantage of profiling, or the user can even 
force the function order.

If the purpose is really to reorder functions, why should the developer 
need to deal with sections? (I mean, not all developers master the 
concept of section, do they?)


Christophe.

Re: RFC: Sort input section by list

[Arjan van de Ven]

Nick Clifton wrote:
> Hi Arjan,
> 
>> I suppose we chose differently; from a distro point of view patching 
>> each app's code that big
>> is a no go for us; once the new binutils is released we can automate 
>> and use the new feature
>> pretty quickly.
>> Add to this that which functions are on the list will also depend on 
>> which arguments you pass to configure...
>> sorry but really the "just patch the code in 3000 places" is really 
>> not going to work ;-(
> 
> Would you agree that if a using-currently-available-tools process could 
> be automated then it would be an acceptable solution to you ?
> 
> Lets assume that you have gotten to the stage where you have the 
> profiled list of functions in the order you wish them to appear in the 
> final binary.  Lets also assume that you have compiled the sources with 
> -ffunction-sections.  You could use a sed/awk script to convert the 
> function names into a linker script fragment that specifically 
> references each of the function sections by name. Then all you would 
> need is a slightly modified default linker script that INCLUDEs this 
> constructed fragment at the right place in the generic linker script.
> 
I've done this before (at my previous employer); it includes getting gcc to dump its linker
script, then running a perl/sed script on it to add this and then finding a way
to get this linker script used. So far so good.
it just becomes impossible in an autoconf/automake/libtool world...
unless we do a gross hack and have an environment variable for such a lookaside linker script instead
(LD_SCRIPT_PREINCLUDE?).. that would solve the issue as well.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:19 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi H.J.
>
>>> A generic method which will work with currently installed versions of gcc
>>> and the linker on most linux boxes...
>>> ...versus a new, untested feature in the linker, in a version of the
>>> linker
>>> that has not even been released yet.
>
>> All linker features were new, untested at one time. It shouldn't be
>> the reason not to implement/experiment them.
>
> True - but I am trying to avoid feature bloat here.  I do not want to add a
> new feature to solve a problem that can already be solved using existing
> methods.
>

As Arjan mentioned, it isn't practical to change so many packages to add
section attribute. It doesn't scale with number of packages nor updates
on packages.

-- 
H.J.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:42 AM, Arjan van de Ven <arjan@linux.intel.com> wrote:
>>
>> Lets assume that you have gotten to the stage where you have the profiled
>> list of functions in the order you wish them to appear in the final binary.
>>  Lets also assume that you have compiled the sources with
>> -ffunction-sections.  You could use a sed/awk script to convert the function
>> names into a linker script fragment that specifically references each of the
>> function sections by name. Then all you would need is a slightly modified
>> default linker script that INCLUDEs this constructed fragment at the right
>> place in the generic linker script.
>>
> I've done this before (at my previous employer); it includes getting gcc to
> dump its linker
> script, then running a perl/sed script on it to add this and then finding a
> way
> to get this linker script used. So far so good.
> it just becomes impossible in an autoconf/automake/libtool world...
> unless we do a gross hack and have an environment variable for such a
> lookaside linker script instead
> (LD_SCRIPT_PREINCLUDE?).. that would solve the issue as well.
>

I am glad to see there are so many feedbacks. My original suggestion
may not be the best approach. I'd like to see examples of other linker
options if possible.

My goals for this new linker features are

1. Users only need to provide lists of sections.
2. The list should support C, C++, Java.
3. The list should work with arbitrary sections.
4. Users don't need to change the default linker script.

Does anyone have other requirements/suggestions?

Thanks.


-- 
H.J.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:42 AM, Arjan van de Ven <arjan@linux.intel.com> wrote:
>>
>> Lets assume that you have gotten to the stage where you have the profiled
>> list of functions in the order you wish them to appear in the final binary.
>>  Lets also assume that you have compiled the sources with
>> -ffunction-sections.  You could use a sed/awk script to convert the function
>> names into a linker script fragment that specifically references each of the
>> function sections by name. Then all you would need is a slightly modified
>> default linker script that INCLUDEs this constructed fragment at the right
>> place in the generic linker script.
>>
> I've done this before (at my previous employer); it includes getting gcc to
> dump its linker
> script, then running a perl/sed script on it to add this and then finding a
> way
> to get this linker script used. So far so good.
> it just becomes impossible in an autoconf/automake/libtool world...
> unless we do a gross hack and have an environment variable for such a
> lookaside linker script instead
> (LD_SCRIPT_PREINCLUDE?).. that would solve the issue as well.
>

I am glad to see there are so many feedbacks. My original suggestion
may not be the best approach. I'd like to see examples of other linker
options if possible.

My goals for this new linker features are

1. Users only need to provide lists of sections.
2. The list should support C, C++, Java.
3. The list should work with arbitrary sections.
4. Users don't need to change the default linker script.

Does anyone have other requirements/suggestions?

Thanks.


-- 
H.J.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:07 AM, Nick Clifton <nickc@redhat.com> wrote:
>
> A generic method which will work with currently installed versions of gcc
> and the linker on most linux boxes...
> ...versus a new, untested feature in the linker, in a version of the linker
> that has not even been released yet.
>

All linker features were new, untested at one time. It shouldn't be
the reason not to implement/experiment them.


-- 
H.J.

Re: RFC: Sort input section by list

[Christophe LYON]

>> What is the real purpose of this feature ?  Ie do you know why it has 
>> been requested ?  The implication of the example you have given is 
>> that the user wants to put certain name-mangled functions at the start 
>> of the .text section, but why ?
> 
> because it allows the developer to put the commonly used functions at 
> the start of the file,
> improving density in the page cache for example, and generally improving 
> startup time.
> (less pagefaults and less TLB pressure)
> 

Why not have a tool dedicated to this kind of optimization?
For one of our targets, we have developed a post linker tool which 
reorders functions based on call graph analysis.

The compiler driver asks the linker to keep all the relocations in the 
generated executable, and then calls the optimizer, which parses the ELF 
file and optionally a "layout file" to reorder code. By default it is 
used to improve locality (we have a direct mapped cache) based on static 
analysis, but can take advantage of profiling, or the user can even 
force the function order.

If the purpose is really to reorder functions, why should the developer 
need to deal with sections? (I mean, not all developers master the 
concept of section, do they?)


Christophe.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:19 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi H.J.
>
>>> A generic method which will work with currently installed versions of gcc
>>> and the linker on most linux boxes...
>>> ...versus a new, untested feature in the linker, in a version of the
>>> linker
>>> that has not even been released yet.
>
>> All linker features were new, untested at one time. It shouldn't be
>> the reason not to implement/experiment them.
>
> True - but I am trying to avoid feature bloat here.  I do not want to add a
> new feature to solve a problem that can already be solved using existing
> methods.
>

As Arjan mentioned, it isn't practical to change so many packages to add
section attribute. It doesn't scale with number of packages nor updates
on packages.

-- 
H.J.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:42 AM, Arjan van de Ven <arjan@linux.intel.com> wrote:
>>
>> Lets assume that you have gotten to the stage where you have the profiled
>> list of functions in the order you wish them to appear in the final binary.
>>  Lets also assume that you have compiled the sources with
>> -ffunction-sections.  You could use a sed/awk script to convert the function
>> names into a linker script fragment that specifically references each of the
>> function sections by name. Then all you would need is a slightly modified
>> default linker script that INCLUDEs this constructed fragment at the right
>> place in the generic linker script.
>>
> I've done this before (at my previous employer); it includes getting gcc to
> dump its linker
> script, then running a perl/sed script on it to add this and then finding a
> way
> to get this linker script used. So far so good.
> it just becomes impossible in an autoconf/automake/libtool world...
> unless we do a gross hack and have an environment variable for such a
> lookaside linker script instead
> (LD_SCRIPT_PREINCLUDE?).. that would solve the issue as well.
>

I am glad to see there are so many feedbacks. My original suggestion
may not be the best approach. I'd like to see examples of other linker
options if possible.

My goals for this new linker features are

1. Users only need to provide lists of sections.
2. The list should support C, C++, Java.
3. The list should work with arbitrary sections.
4. Users don't need to change the default linker script.

Does anyone have other requirements/suggestions?

Thanks.


-- 
H.J.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:07 AM, Nick Clifton <nickc@redhat.com> wrote:
>
> A generic method which will work with currently installed versions of gcc
> and the linker on most linux boxes...
> ...versus a new, untested feature in the linker, in a version of the linker
> that has not even been released yet.
>

All linker features were new, untested at one time. It shouldn't be
the reason not to implement/experiment them.


-- 
H.J.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:19 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi H.J.
>
>>> A generic method which will work with currently installed versions of gcc
>>> and the linker on most linux boxes...
>>> ...versus a new, untested feature in the linker, in a version of the
>>> linker
>>> that has not even been released yet.
>
>> All linker features were new, untested at one time. It shouldn't be
>> the reason not to implement/experiment them.
>
> True - but I am trying to avoid feature bloat here.  I do not want to add a
> new feature to solve a problem that can already be solved using existing
> methods.
>

As Arjan mentioned, it isn't practical to change so many packages to add
section attribute. It doesn't scale with number of packages nor updates
on packages.

-- 
H.J.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:42 AM, Arjan van de Ven <arjan@linux.intel.com> wrote:
>>
>> Lets assume that you have gotten to the stage where you have the profiled
>> list of functions in the order you wish them to appear in the final binary.
>>  Lets also assume that you have compiled the sources with
>> -ffunction-sections.  You could use a sed/awk script to convert the function
>> names into a linker script fragment that specifically references each of the
>> function sections by name. Then all you would need is a slightly modified
>> default linker script that INCLUDEs this constructed fragment at the right
>> place in the generic linker script.
>>
> I've done this before (at my previous employer); it includes getting gcc to
> dump its linker
> script, then running a perl/sed script on it to add this and then finding a
> way
> to get this linker script used. So far so good.
> it just becomes impossible in an autoconf/automake/libtool world...
> unless we do a gross hack and have an environment variable for such a
> lookaside linker script instead
> (LD_SCRIPT_PREINCLUDE?).. that would solve the issue as well.
>

I am glad to see there are so many feedbacks. My original suggestion
may not be the best approach. I'd like to see examples of other linker
options if possible.

My goals for this new linker features are

1. Users only need to provide lists of sections.
2. The list should support C, C++, Java.
3. The list should work with arbitrary sections.
4. Users don't need to change the default linker script.

Does anyone have other requirements/suggestions?

Thanks.


-- 
H.J.

Re: RFC: Sort input section by list

[Daniel Jacobowitz]

On Tue, Aug 26, 2008 at 09:42:47AM -0700, Arjan van de Ven wrote:
> I've done this before (at my previous employer); it includes getting gcc to dump its linker
> script, then running a perl/sed script on it to add this and then finding a way
> to get this linker script used. So far so good.
> it just becomes impossible in an autoconf/automake/libtool world...
> unless we do a gross hack and have an environment variable for such a lookaside linker script instead
> (LD_SCRIPT_PREINCLUDE?).. that would solve the issue as well.

In the latest linker sources Alan's added bits to support additional
linker scripts, instead of replacing the default script.  Then it
reduces to adding an option to the compile command and I'm sure the
distro build process can manage that for most packages.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:19 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi H.J.
>
>>> A generic method which will work with currently installed versions of gcc
>>> and the linker on most linux boxes...
>>> ...versus a new, untested feature in the linker, in a version of the
>>> linker
>>> that has not even been released yet.
>
>> All linker features were new, untested at one time. It shouldn't be
>> the reason not to implement/experiment them.
>
> True - but I am trying to avoid feature bloat here.  I do not want to add a
> new feature to solve a problem that can already be solved using existing
> methods.
>

As Arjan mentioned, it isn't practical to change so many packages to add
section attribute. It doesn't scale with number of packages nor updates
on packages.

-- 
H.J.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 12:19 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, Aug 26, 2008 at 09:42:47AM -0700, Arjan van de Ven wrote:
>> I've done this before (at my previous employer); it includes getting gcc to dump its linker
>> script, then running a perl/sed script on it to add this and then finding a way
>> to get this linker script used. So far so good.
>> it just becomes impossible in an autoconf/automake/libtool world...
>> unless we do a gross hack and have an environment variable for such a lookaside linker script instead
>> (LD_SCRIPT_PREINCLUDE?).. that would solve the issue as well.
>
> In the latest linker sources Alan's added bits to support additional
> linker scripts, instead of replacing the default script.  Then it
> reduces to adding an option to the compile command and I'm sure the
> distro build process can manage that for most packages.
>

Alan added:

`INSERT [ AFTER | BEFORE ] OUTPUT_SECTION'
     This command is typically used in a script specified by `-T' to
     augment the default `SECTIONS' with, for example, overlays.  It
     inserts all prior linker script statements after (or before)
     OUTPUT_SECTION, and also causes `-T' to not override the default
     linker script.  The exact insertion point is as for orphan
     sections.  *Note Location Counter::.  The insertion happens after
     the linker has mapped input sections to output sections.  Prior to
     the insertion, since `-T' scripts are parsed before the default
     linker script, statements in the `-T' script occur before the
     default linker script statements in the internal linker
     representation of the script.  In particular, input section
     assignments will be made to `-T' output sections before those in
     the default script.  Here is an example of how a `-T' script using
     `INSERT' might look:

I don't think it supports sorting input sections.

BTW, this new feature isn't mentioned in ld/NEWS.

-- 
H.J.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:07 AM, Nick Clifton <nickc@redhat.com> wrote:
>
> A generic method which will work with currently installed versions of gcc
> and the linker on most linux boxes...
> ...versus a new, untested feature in the linker, in a version of the linker
> that has not even been released yet.
>

All linker features were new, untested at one time. It shouldn't be
the reason not to implement/experiment them.


-- 
H.J.

Re: RFC: Sort input section by list

[H.J. Lu]

On Tue, Aug 26, 2008 at 9:42 AM, Arjan van de Ven <arjan@linux.intel.com> wrote:
>>
>> Lets assume that you have gotten to the stage where you have the profiled
>> list of functions in the order you wish them to appear in the final binary.
>>  Lets also assume that you have compiled the sources with
>> -ffunction-sections.  You could use a sed/awk script to convert the function
>> names into a linker script fragment that specifically references each of the
>> function sections by name. Then all you would need is a slightly modified
>> default linker script that INCLUDEs this constructed fragment at the right
>> place in the generic linker script.
>>
> I've done this before (at my previous employer); it includes getting gcc to
> dump its linker
> script, then running a perl/sed script on it to add this and then finding a
> way
> to get this linker script used. So far so good.
> it just becomes impossible in an autoconf/automake/libtool world...
> unless we do a gross hack and have an environment variable for such a
> lookaside linker script instead
> (LD_SCRIPT_PREINCLUDE?).. that would solve the issue as well.
>

I am glad to see there are so many feedbacks. My original suggestion
may not be the best approach. I'd like to see examples of other linker
options if possible.

My goals for this new linker features are

1. Users only need to provide lists of sections.
2. The list should support C, C++, Java.
3. The list should work with arbitrary sections.
4. Users don't need to change the default linker script.

Does anyone have other requirements/suggestions?

Thanks.


-- 
H.J.

Re: RFC: Sort input section by list

[Alan Modra]

On Tue, Aug 26, 2008 at 12:45:01PM -0700, H.J. Lu wrote:
> `INSERT [ AFTER | BEFORE ] OUTPUT_SECTION'
> 
> I don't think it supports sorting input sections.

Taking your example, you said you wanted to insert .text._Z3fooi.
amongst other text sections like this:

.text           :
{
    *(.text .stub .text._Z3fooi. .text.* .gnu.linkonce.t.*)
}

It's true that INSERT would not give exactly the same result as the
above, but your example doesn't actually do any sorting!  You probably
meant

.text :
{
    *(.text .stub) *(.text._Z3fooi.) *(.text.* .gnu.linkonce.t.*)
}

You could do this by writing a separate script with

SECTIONS {
  .text : { *(.text .stub) *(.text._Z3fooi.) }
}
INSERT AFTER .init;

Actually, it would be nicer if we could use "INSERT BEFORE .text;"
here, but I think that won't work at the moment.

> BTW, this new feature isn't mentioned in ld/NEWS.

I'll add an entry when I fix the "INSERT BEFORE .text;" issue.

-- 
Alan Modra
Australia Development Lab, IBM

ld output_section_statment related tidy

[Alan Modra]

This patch started off as one to allow INSERT to add a new output
section statement before or after an existing output statement with
the same section name, but ended up just being a cleanup.  The
trouble with allowing an INSERT of the same output section name is
simply that we'd need to allow duplicate output section statements of
the same name, which we don't support currently.  That isn't a
particularly difficult thing to do, but I think it would be safer to
leave that change until we've branched.

	* ldlang.h (lang_output_section_find): Define.
	(lang_output_section_statement_lookup): Update prototype.
	* ldlang.c (lang_output_section_find,
	lang_output_section_statement_lookup_1): Merge into..
	(lang_output_section_statement_lookup): ..here.  Update all callers.
	(process_insert_statements): Set constraint negative
	for output section statements we might be inserting.  Make error
	fatal on not finding insertion section.
	(lang_output_section_find): Rather than comparing
	output_section_statement.constraint against -1, test whether
	it is postive.
	(lang_output_section_statement_lookup_1): Likewise.
	(output_prev_sec_find, strip_excluded_output_sections): Likewise.
	(lang_record_phdrs): Likewise.
	* emultempl/elf32.em (output_rel_find): Likewise.
	* NEWS: Mention INSERT.

Index: ld/NEWS
===================================================================
RCS file: /cvs/src/src/ld/NEWS,v
retrieving revision 1.85
diff -u -p -r1.85 NEWS
--- ld/NEWS	7 Jun 2008 11:35:46 -0000	1.85
+++ ld/NEWS	6 Sep 2008 00:04:49 -0000
@@ -1,6 +1,9 @@
 -*- text -*-
+* Linker scripts support a new INSERT command that makes it easier to
+  augment the default script.
+
 * Linker script input section filespecs may now specify a file within an
- archive by writing "archive:file".
+  archive by writing "archive:file".
 
 * The --sort-common switch now has an optional argument which specifies the
   direction of sorting.
@@ -8,9 +11,9 @@
 * The M68K linker now supports multiple GOT generation schemes controlled via
   the --got=<type> command line option.
 
-* The ARM EABI linker will now generate stubs for function calls to symbols that
-  are too far away.  The placement of the stubs is controlled by a new linker
-  command line option: --stub-group-size=N.
+* The ARM EABI linker will now generate stubs for function calls to symbols
+  that are too far away.  The placement of the stubs is controlled by a new
+  linker command line option: --stub-group-size=N.
 
 Changes in 2.18:
 
Index: ld/ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.291
diff -u -p -r1.291 ldlang.c
--- ld/ldlang.c	21 Aug 2008 13:10:54 -0000	1.291
+++ ld/ldlang.c	6 Sep 2008 00:04:53 -0000
@@ -1149,7 +1149,7 @@ lang_init (void)
   first_file = lang_add_input_file (NULL, lang_input_file_is_marker_enum,
 				    NULL);
   abs_output_section =
-    lang_output_section_statement_lookup (BFD_ABS_SECTION_NAME);
+    lang_output_section_statement_lookup (BFD_ABS_SECTION_NAME, 0, TRUE);
 
   abs_output_section->bfd_section = bfd_abs_section_ptr;
 
@@ -1255,44 +1255,19 @@ lang_memory_default (asection *section)
 }
 
 lang_output_section_statement_type *
-lang_output_section_find (const char *const name)
+lang_output_section_statement_lookup (const char *const name,
+				      int constraint,
+				      bfd_boolean create)
 {
   struct out_section_hash_entry *entry;
-  unsigned long hash;
 
   entry = ((struct out_section_hash_entry *)
 	   bfd_hash_lookup (&output_section_statement_table, name,
-			    FALSE, FALSE));
-  if (entry == NULL)
-    return NULL;
-
-  hash = entry->root.hash;
-  do
-    {
-      if (entry->s.output_section_statement.constraint != -1)
-	return &entry->s.output_section_statement;
-      entry = (struct out_section_hash_entry *) entry->root.next;
-    }
-  while (entry != NULL
-	 && entry->root.hash == hash
-	 && strcmp (name, entry->s.output_section_statement.name) == 0);
-
-  return NULL;
-}
-
-static lang_output_section_statement_type *
-lang_output_section_statement_lookup_1 (const char *const name, int constraint)
-{
-  struct out_section_hash_entry *entry;
-  struct out_section_hash_entry *last_ent;
-  unsigned long hash;
-
-  entry = ((struct out_section_hash_entry *)
-	   bfd_hash_lookup (&output_section_statement_table, name,
-			    TRUE, FALSE));
+			    create, FALSE));
   if (entry == NULL)
     {
-      einfo (_("%P%F: failed creating section `%s': %E\n"), name);
+      if (create)
+	einfo (_("%P%F: failed creating section `%s': %E\n"), name);
       return NULL;
     }
 
@@ -1300,10 +1275,12 @@ lang_output_section_statement_lookup_1 (
     {
       /* We have a section of this name, but it might not have the correct
 	 constraint.  */
-      hash = entry->root.hash;
+      struct out_section_hash_entry *last_ent;
+      unsigned long hash = entry->root.hash;
+
       do
 	{
-	  if (entry->s.output_section_statement.constraint != -1
+	  if (entry->s.output_section_statement.constraint >= 0
 	      && (constraint == 0
 		  || (constraint == entry->s.output_section_statement.constraint
 		      && constraint != SPECIAL)))
@@ -1315,6 +1292,9 @@ lang_output_section_statement_lookup_1 (
 	     && entry->root.hash == hash
 	     && strcmp (name, entry->s.output_section_statement.name) == 0);
 
+      if (!create)
+	return NULL;
+
       entry
 	= ((struct out_section_hash_entry *)
 	   output_section_statement_newfunc (NULL,
@@ -1334,12 +1314,6 @@ lang_output_section_statement_lookup_1 (
   return &entry->s.output_section_statement;
 }
 
-lang_output_section_statement_type *
-lang_output_section_statement_lookup (const char *const name)
-{
-  return lang_output_section_statement_lookup_1 (name, 0);
-}
-
 /* A variant of lang_output_section_find used by place_orphan.
    Returns the output statement that should precede a new output
    statement for SEC.  If an exact match is found on certain flags,
@@ -1502,7 +1476,7 @@ output_prev_sec_find (lang_output_sectio
 
   for (lookup = os->prev; lookup != NULL; lookup = lookup->prev)
     {
-      if (lookup->constraint == -1)
+      if (lookup->constraint < 0)
 	continue;
 
       if (lookup->bfd_section != NULL && lookup->bfd_section->owner != NULL)
@@ -3378,7 +3352,7 @@ map_input_to_output_sections
 	    {
 	      lang_output_section_statement_type *aos
 		= (lang_output_section_statement_lookup
-		   (s->address_statement.section_name));
+		   (s->address_statement.section_name, 0, TRUE));
 
 	      if (aos->bfd_section == NULL)
 		init_os (aos, NULL, 0);
@@ -3403,6 +3377,7 @@ process_insert_statements (void)
   lang_statement_union_type **s;
   lang_output_section_statement_type *first_os = NULL;
   lang_output_section_statement_type *last_os = NULL;
+  lang_output_section_statement_type *os;
 
   /* "start of list" is actually the statement immediately after
      the special abs_section output statement, so that it isn't
@@ -3415,6 +3390,12 @@ process_insert_statements (void)
 	  /* Keep pointers to the first and last output section
 	     statement in the sequence we may be about to move.  */
 	  last_os = &(*s)->output_section_statement;
+
+	  /* Set constraint negative so that lang_output_section_find
+	     won't match this output section statement.  At this
+	     stage in linking constraint has values in the range
+	     [-1, ONLY_IN_RW].  */
+	  last_os->constraint = -2 - last_os->constraint;
 	  if (first_os == NULL)
 	    first_os = last_os;
 	}
@@ -3422,7 +3403,6 @@ process_insert_statements (void)
 	{
 	  lang_insert_statement_type *i = &(*s)->insert_statement;
 	  lang_output_section_statement_type *where;
-	  lang_output_section_statement_type *os;
 	  lang_statement_union_type **ptr;
 	  lang_statement_union_type *first;
 
@@ -3431,21 +3411,12 @@ process_insert_statements (void)
 	    {
 	      do
 		where = where->prev;
-	      while (where != NULL && where->constraint == -1);
+	      while (where != NULL && where->constraint < 0);
 	    }
 	  if (where == NULL)
 	    {
-	      einfo (_("%X%P: %s not found for insert\n"), i->where);
-	      continue;
-	    }
-	  /* You can't insert into the list you are moving.  */
-	  for (os = first_os; os != NULL; os = os->next)
-	    if (os == where || os == last_os)
-	      break;
-	  if (os == where)
-	    {
-	      einfo (_("%X%P: %s not found for insert\n"), i->where);
-	      continue;
+	      einfo (_("%F%P: %s not found for insert\n"), i->where);
+	      return;
 	    }
 
 	  /* Deal with reordering the output section statement list.  */
@@ -3482,6 +3453,7 @@ process_insert_statements (void)
 	      last_sec = NULL;
 	      for (os = first_os; os != NULL; os = os->next)
 		{
+		  os->constraint = -2 - os->constraint;
 		  if (os->bfd_section != NULL
 		      && os->bfd_section->owner != NULL)
 		    {
@@ -3542,6 +3514,14 @@ process_insert_statements (void)
 	  s = &lang_output_section_statement.head;
 	}
     }
+
+  /* Undo constraint twiddling.  */
+  for (os = first_os; os != NULL; os = os->next)
+    {
+      os->constraint = -2 - os->constraint;
+      if (os == last_os)
+	break;
+    }
 }
 
 /* An output section might have been removed after its statement was
@@ -3569,7 +3549,7 @@ strip_excluded_output_sections (void)
       asection *output_section;
       bfd_boolean exclude;
 
-      if (os->constraint == -1)
+      if (os->constraint < 0)
 	continue;
 
       output_section = os->bfd_section;
@@ -5665,11 +5645,9 @@ lang_place_orphans (void)
 		      || command_line.force_common_definition)
 		    {
 		      if (default_common_section == NULL)
-			{
-			  default_common_section =
-			    lang_output_section_statement_lookup (".bss");
-
-			}
+			default_common_section
+			  = lang_output_section_statement_lookup (".bss", 0,
+								  TRUE);
 		      lang_add_section (&default_common_section->children, s,
 					default_common_section);
 		    }
@@ -5680,7 +5658,7 @@ lang_place_orphans (void)
 		{
 		  lang_output_section_statement_type *os;
 
-		  os = lang_output_section_statement_lookup (s->name);
+		  os = lang_output_section_statement_lookup (s->name, 0, TRUE);
 		  lang_add_section (&os->children, s, os);
 		}
 	    }
@@ -5827,12 +5805,10 @@ lang_enter_output_section_statement (con
 {
   lang_output_section_statement_type *os;
 
-  os = lang_output_section_statement_lookup_1 (output_section_statement_name,
-					       constraint);
+  os = lang_output_section_statement_lookup (output_section_statement_name,
+					     constraint, TRUE);
   current_section = os;
 
-  /* Make next things chain into subchain of this.  */
-
   if (os->addr_tree == NULL)
     {
       os->addr_tree = address_exp;
@@ -5843,6 +5819,8 @@ lang_enter_output_section_statement (con
   else
     os->flags = SEC_NEVER_LOAD;
   os->block_value = 1;
+
+  /* Make next things chain into subchain of this.  */
   stat_ptr = &os->children;
 
   os->subsection_alignment =
@@ -6639,7 +6617,7 @@ lang_record_phdrs (void)
 	{
 	  lang_output_section_phdr_list *pl;
 
-	  if (os->constraint == -1)
+	  if (os->constraint < 0)
 	    continue;
 
 	  pl = os->phdrs;
@@ -6720,7 +6698,7 @@ lang_record_phdrs (void)
     {
       lang_output_section_phdr_list *pl;
 
-      if (os->constraint == -1
+      if (os->constraint < 0
 	  || os->bfd_section == NULL)
 	continue;
 
Index: ld/ldlang.h
===================================================================
RCS file: /cvs/src/src/ld/ldlang.h,v
retrieving revision 1.78
diff -u -p -r1.78 ldlang.h
--- ld/ldlang.h	17 Aug 2008 03:12:50 -0000	1.78
+++ ld/ldlang.h	6 Sep 2008 00:04:54 -0000
@@ -525,12 +525,13 @@ extern void lang_do_assignments
        statement != (lang_input_statement_type *) NULL;			\
        statement = (lang_input_statement_type *) statement->next)	\
 
+#define lang_output_section_find(NAME) \
+  lang_output_section_statement_lookup (NAME, 0, FALSE)
+
 extern void lang_process
   (void);
 extern void ldlang_add_file
   (lang_input_statement_type *);
-extern lang_output_section_statement_type *lang_output_section_find
-  (const char * const);
 extern lang_output_section_statement_type *lang_output_section_find_by_flags
   (const asection *, lang_output_section_statement_type **,
    lang_match_sec_type_func);
@@ -541,9 +542,8 @@ extern lang_input_statement_type *lang_a
   (const char *, lang_input_file_enum_type, const char *);
 extern void lang_add_keepsyms_file
   (const char *);
-extern lang_output_section_statement_type *
-  lang_output_section_statement_lookup
-  (const char *const);
+extern lang_output_section_statement_type *lang_output_section_statement_lookup
+  (const char *const, int, bfd_boolean);
 extern void ldlang_add_undef
   (const char *const);
 extern void lang_add_output_format
Index: ld/emultempl/beos.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/beos.em,v
retrieving revision 1.39
diff -u -p -r1.39 beos.em
--- ld/emultempl/beos.em	15 Feb 2008 03:35:53 -0000	1.39
+++ ld/emultempl/beos.em	6 Sep 2008 00:04:55 -0000
@@ -697,7 +697,7 @@ gld${EMULATION_NAME}_place_orphan (asect
   output_secname = xstrdup (secname);
   ps = strchr (output_secname + 1, '\$');
   *ps = 0;
-  os = lang_output_section_statement_lookup (output_secname);
+  os = lang_output_section_statement_lookup (output_secname, 0, TRUE);
 
   /* Find the '\$' wild statement for this section.  We currently require the
      linker script to explicitly mention "*(.foo\$)".
Index: ld/emultempl/elf32.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/elf32.em,v
retrieving revision 1.191
diff -u -p -r1.191 elf32.em
--- ld/emultempl/elf32.em	8 Aug 2008 08:06:16 -0000	1.191
+++ ld/emultempl/elf32.em	6 Sep 2008 00:04:56 -0000
@@ -1583,7 +1583,7 @@ output_rel_find (asection *sec, int isdy
        lookup != NULL;
        lookup = lookup->next)
     {
-      if (lookup->constraint != -1
+      if (lookup->constraint >= 0
 	  && CONST_STRNEQ (lookup->name, ".rel"))
 	{
 	  int lookrela = lookup->name[4] == 'a';
Index: ld/emultempl/sunos.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/sunos.em,v
retrieving revision 1.30
diff -u -p -r1.30 sunos.em
--- ld/emultempl/sunos.em	15 Feb 2008 03:35:53 -0000	1.30
+++ ld/emultempl/sunos.em	6 Sep 2008 00:04:56 -0000
@@ -698,7 +698,7 @@ gld${EMULATION_NAME}_before_allocation (
 
       /* Set the .text section to start at 0x20, not 0x2020.  FIXME:
 	 This is too magical.  */
-      os = lang_output_section_statement_lookup (".text");
+      os = lang_output_section_statement_lookup (".text", 0, TRUE);
       if (os->addr_tree == NULL)
 	os->addr_tree = exp_intop (0x20);
     }

-- 
Alan Modra
Australia Development Lab, IBM

build failure on the branch (Re: ld output_section_statment related tidy)

[Matthias Klose]

looks like these two chunks are not mentioned in the ChangeLog, and not applied
(at least on the 2.19 branch):

gcc -DHAVE_CONFIG_H -I. -I../../ld -I. -I. -I../../ld -I../bfd -I../../ld/../bfd
-I../../ld/../include  -g -O2 -Wno-format-security
-DLOCALEDIR="\"/usr/share/locale\""   -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror -g -O2 -Wno-format-security -c esun4.c
esun4.c: In function 'gldsun4_before_allocation':
esun4.c:644: error: too few arguments to function
'lang_output_section_statement_lookup'
make[5]: *** [esun4.o] Error 1

  Matthias

Alan Modra schrieb:
> This patch started off as one to allow INSERT to add a new output
> section statement before or after an existing output statement with
> the same section name, but ended up just being a cleanup.  The
> trouble with allowing an INSERT of the same output section name is
> simply that we'd need to allow duplicate output section statements of
> the same name, which we don't support currently.  That isn't a
> particularly difficult thing to do, but I think it would be safer to
> leave that change until we've branched.
> 
> 	* ldlang.h (lang_output_section_find): Define.
> 	(lang_output_section_statement_lookup): Update prototype.
> 	* ldlang.c (lang_output_section_find,
> 	lang_output_section_statement_lookup_1): Merge into..
> 	(lang_output_section_statement_lookup): ..here.  Update all callers.
> 	(process_insert_statements): Set constraint negative
> 	for output section statements we might be inserting.  Make error
> 	fatal on not finding insertion section.
> 	(lang_output_section_find): Rather than comparing
> 	output_section_statement.constraint against -1, test whether
> 	it is postive.
> 	(lang_output_section_statement_lookup_1): Likewise.
> 	(output_prev_sec_find, strip_excluded_output_sections): Likewise.
> 	(lang_record_phdrs): Likewise.
> 	* emultempl/elf32.em (output_rel_find): Likewise.
> 	* NEWS: Mention INSERT.

> Index: ld/emultempl/beos.em
> ===================================================================
> RCS file: /cvs/src/src/ld/emultempl/beos.em,v
> retrieving revision 1.39
> diff -u -p -r1.39 beos.em
> --- ld/emultempl/beos.em	15 Feb 2008 03:35:53 -0000	1.39
> +++ ld/emultempl/beos.em	6 Sep 2008 00:04:55 -0000
> @@ -697,7 +697,7 @@ gld${EMULATION_NAME}_place_orphan (asect
>    output_secname = xstrdup (secname);
>    ps = strchr (output_secname + 1, '\$');
>    *ps = 0;
> -  os = lang_output_section_statement_lookup (output_secname);
> +  os = lang_output_section_statement_lookup (output_secname, 0, TRUE);
>  
>    /* Find the '\$' wild statement for this section.  We currently require the
>       linker script to explicitly mention "*(.foo\$)".

> Index: ld/emultempl/sunos.em
> ===================================================================
> RCS file: /cvs/src/src/ld/emultempl/sunos.em,v
> retrieving revision 1.30
> diff -u -p -r1.30 sunos.em
> --- ld/emultempl/sunos.em	15 Feb 2008 03:35:53 -0000	1.30
> +++ ld/emultempl/sunos.em	6 Sep 2008 00:04:56 -0000
> @@ -698,7 +698,7 @@ gld${EMULATION_NAME}_before_allocation (
>  
>        /* Set the .text section to start at 0x20, not 0x2020.  FIXME:
>  	 This is too magical.  */
> -      os = lang_output_section_statement_lookup (".text");
> +      os = lang_output_section_statement_lookup (".text", 0, TRUE);
>        if (os->addr_tree == NULL)
>  	os->addr_tree = exp_intop (0x20);
>      }
> 

Re: build failure on the branch (Re: ld output_section_statment related tidy)

[H.J. Lu]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

On Mon, Sep 8, 2008 at 7:39 AM, Matthias Klose <doko@ubuntu.com> wrote:
> looks like these two chunks are not mentioned in the ChangeLog, and not applied
> (at least on the 2.19 branch):
>
> gcc -DHAVE_CONFIG_H -I. -I../../ld -I. -I. -I../../ld -I../bfd -I../../ld/../bfd
> -I../../ld/../include  -g -O2 -Wno-format-security
> -DLOCALEDIR="\"/usr/share/locale\""   -W -Wall -Wstrict-prototypes
> -Wmissing-prototypes -Werror -g -O2 -Wno-format-security -c esun4.c
> esun4.c: In function 'gldsun4_before_allocation':
> esun4.c:644: error: too few arguments to function
> 'lang_output_section_statement_lookup'
> make[5]: *** [esun4.o] Error 1
>

I am checking in this patch as an obvious fix. I also recommend it
for 2.19 branch.


-- 
H.J.

[-- Attachment #2: d.txt --]
[-- Type: text/plain, Size: 2027 bytes --]

? autom4te.cache
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/ld/ChangeLog,v
retrieving revision 1.1868
diff -u -p -r1.1868 ChangeLog
--- ChangeLog	8 Sep 2008 08:56:56 -0000	1.1868
+++ ChangeLog	8 Sep 2008 16:07:22 -0000
@@ -1,3 +1,10 @@
+2008-09-08  H.J. Lu  <hongjiu.lu@intel.com>
+
+	2008-09-07  Alan Modra  <amodra@bigpond.net.au>
+
+	* emultempl/beos.em (gld${EMULATION_NAME}_place_orphan): Updated.
+	* emultempl/sunos.em (gld${EMULATION_NAME}_before_allocation): Likewise.
+
 2008-09-08  Tristan Gingold  <gingold@adacore.com>
 
 	* NEWS: Add a marker for the 2.19 features.
Index: emultempl/beos.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/beos.em,v
retrieving revision 1.39
diff -u -p -r1.39 beos.em
--- emultempl/beos.em	15 Feb 2008 03:35:53 -0000	1.39
+++ emultempl/beos.em	8 Sep 2008 16:07:22 -0000
@@ -697,7 +697,7 @@ gld${EMULATION_NAME}_place_orphan (asect
   output_secname = xstrdup (secname);
   ps = strchr (output_secname + 1, '\$');
   *ps = 0;
-  os = lang_output_section_statement_lookup (output_secname);
+  os = lang_output_section_statement_lookup (output_secname, 0, TRUE);
 
   /* Find the '\$' wild statement for this section.  We currently require the
      linker script to explicitly mention "*(.foo\$)".
Index: emultempl/sunos.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/sunos.em,v
retrieving revision 1.30
diff -u -p -r1.30 sunos.em
--- emultempl/sunos.em	15 Feb 2008 03:35:53 -0000	1.30
+++ emultempl/sunos.em	8 Sep 2008 16:07:22 -0000
@@ -698,7 +698,7 @@ gld${EMULATION_NAME}_before_allocation (
 
       /* Set the .text section to start at 0x20, not 0x2020.  FIXME:
 	 This is too magical.  */
-      os = lang_output_section_statement_lookup (".text");
+      os = lang_output_section_statement_lookup (".text", 0, TRUE);
       if (os->addr_tree == NULL)
 	os->addr_tree = exp_intop (0x20);
     }

Re: build failure on the branch (Re: ld output_section_statment related tidy)

[Alan Modra]

On Mon, Sep 08, 2008 at 09:09:35AM -0700, H.J. Lu wrote:
> I am checking in this patch as an obvious fix. I also recommend it
> for 2.19 branch.

Oops.  I've applied them to 2.19 too.

-- 
Alan Modra
Australia Development Lab, IBM

Re: ld output_section_statment related tidy

[Andreas Schwab]

Alan Modra <amodra@bigpond.net.au> writes:

> 	* ldlang.h (lang_output_section_find): Define.
> 	(lang_output_section_statement_lookup): Update prototype.
> 	* ldlang.c (lang_output_section_find,
> 	lang_output_section_statement_lookup_1): Merge into..
> 	(lang_output_section_statement_lookup): ..here.  Update all callers.
> 	(process_insert_statements): Set constraint negative
> 	for output section statements we might be inserting.  Make error
> 	fatal on not finding insertion section.
> 	(lang_output_section_find): Rather than comparing
> 	output_section_statement.constraint against -1, test whether
> 	it is postive.
> 	(lang_output_section_statement_lookup_1): Likewise.
> 	(output_prev_sec_find, strip_excluded_output_sections): Likewise.

This is causing the linker to crash in bfd_elf_final_link when trying to
iterate over map_head.link_order, because strip_excluded_output_sections
no long clears out this field from all sections and leaves the previous
value in it which is still a bfd_section, not a bfd_link_order.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ld output_section_statment related tidy

[Alan Modra]

On Sun, Feb 15, 2009 at 03:23:18PM +0100, Andreas Schwab wrote:
> Alan Modra <amodra@bigpond.net.au> writes:
> > Can you tell me how to reproduce the crash?
> 
> See <https://bugzilla.novell.com/attachment.cgi?id=269567>.

process_insert_statements walks the statement list, setting
"constraint" negative for any output section statements it finds while
looking for an insert statement.  If no insert statement was found it
resets the constraints by walking the output statement list.  This is
a different list, but it ought to be in the same order as the full
statement list.  Of course, it wasn't.  The testcase is missing a -T
on the command line, and manages to find a place in ld where we allow
the lists to become inconsistent.

	* ldlang.c (push_stat_ptr, pop_stat_ptr): New functions.
	(stat_save, stat_save_ptr): New variables.
	(lang_insert_orphan): Use push_stat_ptr and pop_stat_ptr.
	(load_symbols): Likewise.  Delete dead "bad_load" code.
	(open_input_bfds): Warn on script containing output sections.
	(lang_enter_output_section_statement): Use push_stat_ptr.
	(lang_enter_group): Likewise.
	(lang_leave_output_section_statement): Use pop_stat_ptr.
	(lang_leave_group): Likewise.
	* ldlang.h (push_stat_ptr, pop_stat_ptr): Declare.
	* ldctor.c (ldctor_build_sets): Use push_stat_ptr and pop_stat_ptr.
	* emultempl/beos.em (gld_${EMULATION_NAME}_set_symbols): Likewise.
	* emultempl/pe.em (gld_${EMULATION_NAME}_set_symbols): Likewise.
	* emultempl/pep.em (gld_${EMULATION_NAME}_set_symbols): Likewise.
	* emultempl/spuelf.em (spu_place_special_section): Likewise.
	* emultempl/xtensaelf.em (ld_xtensa_insert_page_offsets): Likewise.

Index: ld/ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.299
diff -u -p -r1.299 ldlang.c
--- ld/ldlang.c	9 Feb 2009 14:46:40 -0000	1.299
+++ ld/ldlang.c	16 Feb 2009 06:25:23 -0000
@@ -64,6 +64,8 @@ static const char *current_target;
 static const char *output_target;
 static lang_statement_list_type statement_list;
 static struct bfd_hash_table lang_definedness_table;
+static lang_statement_list_type *stat_save[10];
+static lang_statement_list_type **stat_save_ptr = &stat_save[0];
 
 /* Forward declarations.  */
 static void exp_init_os (etree_type *);
@@ -925,6 +927,23 @@ lang_list_init (lang_statement_list_type
   list->tail = &list->head;
 }
 
+void
+push_stat_ptr (lang_statement_list_type *new_ptr)
+{
+  if (stat_save_ptr >= stat_save + sizeof (stat_save) / sizeof (stat_save[0]))
+    abort ();
+  *stat_save_ptr++ = stat_ptr;
+  stat_ptr = new_ptr;
+}
+
+void
+pop_stat_ptr (void)
+{
+  if (stat_save_ptr <= stat_save)
+    abort ();
+  stat_ptr = *--stat_save_ptr;
+}
+
 /* Build a new statement node for the parse tree.  */
 
 static lang_statement_union_type *
@@ -1586,23 +1605,18 @@ lang_insert_orphan (asection *s,
 		    etree_type *address,
 		    lang_statement_list_type *add_child)
 {
-  lang_statement_list_type *old;
   lang_statement_list_type add;
   const char *ps;
   lang_output_section_statement_type *os;
   lang_output_section_statement_type **os_tail;
 
-  /* Start building a list of statements for this section.
-     First save the current statement pointer.  */
-  old = stat_ptr;
-
   /* If we have found an appropriate place for the output section
      statements for this orphan, add them to our own private list,
      inserting them later into the global statement list.  */
   if (after != NULL)
     {
-      stat_ptr = &add;
-      lang_list_init (stat_ptr);
+      lang_list_init (&add);
+      push_stat_ptr (&add);
     }
 
   ps = NULL;
@@ -1648,11 +1662,6 @@ lang_insert_orphan (asection *s,
     {
       char *symname;
 
-      /* lang_leave_ouput_section_statement resets stat_ptr.
-	 Put stat_ptr back where we want it.  */
-      if (after != NULL)
-	stat_ptr = &add;
-
       symname = (char *) xmalloc (ps - secname + sizeof "__stop_" + 1);
       symname[0] = bfd_get_symbol_leading_char (link_info.output_bfd);
       sprintf (symname + (symname[0] != 0), "__stop_%s", secname);
@@ -1663,7 +1672,7 @@ lang_insert_orphan (asection *s,
 
   /* Restore the global list pointer.  */
   if (after != NULL)
-    stat_ptr = old;
+    pop_stat_ptr ();
 
   if (after != NULL && os->bfd_section != NULL)
     {
@@ -1749,8 +1758,8 @@ lang_insert_orphan (asection *s,
 
 	  /* Fix the global list pointer if we happened to tack our
 	     new list at the tail.  */
-	  if (*old->tail == add.head)
-	    old->tail = add.tail;
+	  if (*stat_ptr->tail == add.head)
+	    stat_ptr->tail = add.tail;
 
 	  /* Save the end of this list.  */
 	  place->stmt = add.tail;
@@ -2481,8 +2490,6 @@ load_symbols (lang_input_statement_type 
       && ! bfd_check_format_matches (entry->the_bfd, bfd_object, &matching))
     {
       bfd_error_type err;
-      lang_statement_list_type *hold;
-      bfd_boolean bad_load = TRUE;
       bfd_boolean save_ldlang_sysrooted_script;
       bfd_boolean save_as_needed, save_add_needed;
 
@@ -2505,8 +2512,6 @@ load_symbols (lang_input_statement_type 
       else if (err != bfd_error_file_not_recognized
 	       || place == NULL)
 	einfo (_("%F%B: file not recognized: %E\n"), entry->the_bfd);
-      else
-	bad_load = FALSE;
 
       bfd_close (entry->the_bfd);
       entry->the_bfd = NULL;
@@ -2514,8 +2519,7 @@ load_symbols (lang_input_statement_type 
       /* Try to interpret the file as a linker script.  */
       ldfile_open_command_file (entry->filename);
 
-      hold = stat_ptr;
-      stat_ptr = place;
+      push_stat_ptr (place);
       save_ldlang_sysrooted_script = ldlang_sysrooted_script;
       ldlang_sysrooted_script = entry->sysrooted;
       save_as_needed = as_needed;
@@ -2534,9 +2538,9 @@ load_symbols (lang_input_statement_type 
       ldlang_sysrooted_script = save_ldlang_sysrooted_script;
       as_needed = save_as_needed;
       add_needed = save_add_needed;
-      stat_ptr = hold;
+      pop_stat_ptr ();
 
-      return ! bad_load;
+      return TRUE;
     }
 
   if (ldemul_recognized_file (entry))
@@ -3008,6 +3012,7 @@ open_input_bfds (lang_statement_union_ty
 	case lang_input_statement_enum:
 	  if (s->input_statement.real)
 	    {
+	      lang_statement_union_type **os_tail;
 	      lang_statement_list_type add;
 
 	      s->input_statement.target = current_target;
@@ -3023,6 +3028,7 @@ open_input_bfds (lang_statement_union_ty
 				       bfd_archive))
 		s->input_statement.loaded = FALSE;
 
+	      os_tail = lang_output_section_statement.tail;
 	      lang_list_init (&add);
 
 	      if (! load_symbols (&s->input_statement, &add))
@@ -3030,8 +3036,25 @@ open_input_bfds (lang_statement_union_ty
 
 	      if (add.head != NULL)
 		{
-		  *add.tail = s->header.next;
-		  s->header.next = add.head;
+		  /* If this was a script with output sections then
+		     tack any added statements on to the end of the
+		     list.  This avoids having to reorder the output
+		     section statement list.  Very likely the user
+		     forgot -T, and whatever we do here will not meet
+		     naive user expectations.  */
+		  if (os_tail != lang_output_section_statement.tail)
+		    {
+		      einfo (_("%P: warning: %s contains output sections;"
+			       " did you forget -T?\n"),
+			     s->input_statement.filename);
+		      *stat_ptr->tail = add.head;
+		      stat_ptr->tail = add.tail;
+		    }
+		  else
+		    {
+		      *add.tail = s->header.next;
+		      s->header.next = add.head;
+		    }
 		}
 	    }
 	  break;
@@ -5860,7 +5883,7 @@ lang_enter_output_section_statement (con
   os->block_value = 1;
 
   /* Make next things chain into subchain of this.  */
-  stat_ptr = &os->children;
+  push_stat_ptr (&os->children);
 
   os->subsection_alignment =
     topower (exp_get_value_int (subalign, -1, "subsection alignment"));
@@ -6468,7 +6491,7 @@ lang_leave_output_section_statement (fil
 		    current_section->addr_tree != NULL);
   current_section->fill = fill;
   current_section->phdrs = phdrs;
-  stat_ptr = &statement_list;
+  pop_stat_ptr ();
 }
 
 /* Create an absolute symbol with the given name with the value of the
@@ -6585,7 +6608,7 @@ lang_enter_group (void)
 
   g = new_stat (lang_group_statement, stat_ptr);
   lang_list_init (&g->children);
-  stat_ptr = &g->children;
+  push_stat_ptr (&g->children);
 }
 
 /* Leave a group.  This just resets stat_ptr to start writing to the
@@ -6596,7 +6619,7 @@ lang_enter_group (void)
 void
 lang_leave_group (void)
 {
-  stat_ptr = &statement_list;
+  pop_stat_ptr ();
 }
 
 /* Add a new program header.  This is called for each entry in a PHDRS
Index: ld/ldlang.h
===================================================================
RCS file: /cvs/src/src/ld/ldlang.h,v
retrieving revision 1.80
diff -u -p -r1.80 ldlang.h
--- ld/ldlang.h	4 Oct 2008 06:08:59 -0000	1.80
+++ ld/ldlang.h	16 Feb 2009 06:25:24 -0000
@@ -550,6 +550,10 @@ extern void lang_add_output_format
   (const char *, const char *, const char *, int);
 extern void lang_list_init
   (lang_statement_list_type *);
+extern void push_stat_ptr
+  (lang_statement_list_type *);
+extern void pop_stat_ptr
+  (void);
 extern void lang_add_data
   (int type, union etree_union *);
 extern void lang_add_reloc
Index: ld/ldctor.c
===================================================================
RCS file: /cvs/src/src/ld/ldctor.c,v
retrieving revision 1.14
diff -u -p -r1.14 ldctor.c
--- ld/ldctor.c	15 Feb 2008 03:35:53 -0000	1.14
+++ ld/ldctor.c	16 Feb 2009 06:25:19 -0000
@@ -198,7 +198,6 @@ void
 ldctor_build_sets (void)
 {
   static bfd_boolean called;
-  lang_statement_list_type *old;
   bfd_boolean header_printed;
   struct set_info *p;
 
@@ -244,10 +243,8 @@ ldctor_build_sets (void)
 	}
     }
 
-  old = stat_ptr;
-  stat_ptr = &constructor_list;
-
-  lang_list_init (stat_ptr);
+  lang_list_init (&constructor_list);
+  push_stat_ptr (&constructor_list);
 
   header_printed = FALSE;
   for (p = sets; p != NULL; p = p->next)
@@ -372,5 +369,5 @@ ldctor_build_sets (void)
       lang_add_data (size, exp_intop (0));
     }
 
-  stat_ptr = old;
+  pop_stat_ptr ();
 }
Index: ld/emultempl/beos.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/beos.em,v
retrieving revision 1.43
diff -u -p -r1.43 beos.em
--- ld/emultempl/beos.em	20 Oct 2008 12:14:29 -0000	1.43
+++ ld/emultempl/beos.em	16 Feb 2009 06:25:24 -0000
@@ -330,7 +330,6 @@ gld_${EMULATION_NAME}_set_symbols (void)
   /* Run through and invent symbols for all the
      names and insert the defaults. */
   int j;
-  lang_statement_list_type *save;
 
   if (!init[IMAGEBASEOFF].inited)
     {
@@ -347,9 +346,7 @@ gld_${EMULATION_NAME}_set_symbols (void)
     return;
 
   /* Glue the assignments into the abs section */
-  save = stat_ptr;
-
-  stat_ptr = &(abs_output_section->children);
+  push_stat_ptr (&abs_output_section->children);
 
   for (j = 0; init[j].ptr; j++)
     {
@@ -367,7 +364,7 @@ gld_${EMULATION_NAME}_set_symbols (void)
       else	abort();
     }
   /* Restore the pointer. */
-  stat_ptr = save;
+  pop_stat_ptr ();
 
   if (pe.FileAlignment >
       pe.SectionAlignment)
@@ -609,8 +606,6 @@ sort_sections (lang_statement_union_type
 static void
 gld_${EMULATION_NAME}_before_allocation (void)
 {
-  extern lang_statement_list_type *stat_ptr;
-
 #ifdef TARGET_IS_ppcpe
   /* Here we rummage through the found bfds to collect toc information */
   {
Index: ld/emultempl/pe.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/pe.em,v
retrieving revision 1.141
diff -u -p -r1.141 pe.em
--- ld/emultempl/pe.em	8 Jan 2009 13:28:48 -0000	1.141
+++ ld/emultempl/pe.em	16 Feb 2009 06:25:26 -0000
@@ -725,7 +725,6 @@ gld_${EMULATION_NAME}_set_symbols (void)
   /* Run through and invent symbols for all the
      names and insert the defaults.  */
   int j;
-  lang_statement_list_type *save;
 
   if (!init[IMAGEBASEOFF].inited)
     {
@@ -748,9 +747,7 @@ gld_${EMULATION_NAME}_set_symbols (void)
     return;
 
   /* Glue the assignments into the abs section.  */
-  save = stat_ptr;
-
-  stat_ptr = &(abs_output_section->children);
+  push_stat_ptr (&abs_output_section->children);
 
   for (j = 0; init[j].ptr; j++)
     {
@@ -772,7 +769,7 @@ gld_${EMULATION_NAME}_set_symbols (void)
 	image_base_statement = rv;
     }
   /* Restore the pointer.  */
-  stat_ptr = save;
+  pop_stat_ptr ();
 
   if (pe.FileAlignment >
       pe.SectionAlignment)
Index: ld/emultempl/pep.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/pep.em,v
retrieving revision 1.20
diff -u -p -r1.20 pep.em
--- ld/emultempl/pep.em	8 Jan 2009 13:28:48 -0000	1.20
+++ ld/emultempl/pep.em	16 Feb 2009 06:25:27 -0000
@@ -681,7 +681,6 @@ gld_${EMULATION_NAME}_set_symbols (void)
   /* Run through and invent symbols for all the
      names and insert the defaults.  */
   int j;
-  lang_statement_list_type *save;
 
   if (!init[IMAGEBASEOFF].inited)
     {
@@ -704,9 +703,7 @@ gld_${EMULATION_NAME}_set_symbols (void)
     return;
 
   /* Glue the assignments into the abs section.  */
-  save = stat_ptr;
-
-  stat_ptr = &(abs_output_section->children);
+  push_stat_ptr (&abs_output_section->children);
 
   for (j = 0; init[j].ptr; j++)
     {
@@ -728,7 +725,7 @@ gld_${EMULATION_NAME}_set_symbols (void)
 	image_base_statement = rv;
     }
   /* Restore the pointer.  */
-  stat_ptr = save;
+  pop_stat_ptr ();
 
   if (pep.FileAlignment > pep.SectionAlignment)
     {
Index: ld/emultempl/spuelf.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/spuelf.em,v
retrieving revision 1.33
diff -u -p -r1.33 spuelf.em
--- ld/emultempl/spuelf.em	4 Feb 2009 02:43:17 -0000	1.33
+++ ld/emultempl/spuelf.em	16 Feb 2009 06:25:27 -0000
@@ -160,12 +160,11 @@ spu_place_special_section (asection *s, 
 	  /* Pad this stub section so that it finishes at the
 	     end of the icache line.  */
 	  etree_type *e_size;
-	  lang_statement_list_type *save = stat_ptr;
 
-	  stat_ptr = &os->children;
+	  push_stat_ptr (&os->children);
 	  e_size = exp_intop (params.line_size - s->size);
 	  lang_add_assignment (exp_assop ('=', ".", e_size));
-	  stat_ptr = save;
+	  pop_stat_ptr ();
 	}
       lang_add_section (&os->children, s, os);
     }
@@ -558,7 +557,7 @@ embedded_spu_file (lang_input_statement_
   if (lang_add_input_file (oname, lang_input_file_is_file_enum, NULL) == NULL)
     return FALSE;
 
-  /* lang_add_input_file put the new list entry at the end of the statement
+  /* lang_add_input_file puts the new list entry at the end of the statement
      and input file lists.  Move it to just after the current entry.  */
   new_ent = *old_stat_tail;
   *old_stat_tail = NULL;
Index: ld/emultempl/xtensaelf.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/xtensaelf.em,v
retrieving revision 1.22
diff -u -p -r1.22 xtensaelf.em
--- ld/emultempl/xtensaelf.em	15 Feb 2008 03:35:53 -0000	1.22
+++ ld/emultempl/xtensaelf.em	16 Feb 2009 06:25:29 -0000
@@ -1951,20 +1951,17 @@ ld_xtensa_insert_page_offsets (bfd_vma d
 		lang_assignment_statement_type *assign_stmt;
 		lang_statement_union_type *assign_union;
 		lang_statement_list_type tmplist;
-		lang_statement_list_type *old_stat_ptr = stat_ptr;
 
 		/* There is hidden state in "lang_add_assignment".  It
 		   appends the new assignment statement to the stat_ptr
 		   list.  Thus, we swap it before and after the call.  */
 
-		tmplist.head = NULL;
-		tmplist.tail = &tmplist.head;
-
-		stat_ptr = &tmplist;
+		lang_list_init (&tmplist);
+		push_stat_ptr (&tmplist);
 		/* Warning: side effect; statement appended to stat_ptr.  */
 		assign_stmt = lang_add_assignment (assign_op);
 		assign_union = (lang_statement_union_type *) assign_stmt;
-		stat_ptr = old_stat_ptr;
+		pop_stat_ptr ();
 
 		assign_union->header.next = l;
 		*(*stack_p)->iterloc.loc = assign_union;


-- 
Alan Modra
Australia Development Lab, IBM

Re: ld output_section_statment related tidy

[Alan Modra]

This should make sure we keep the lists consistent.

	* ldlang.c (process_insert_statements): ASSERT that output section
	statements are in order.

Index: ld/ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.300
diff -u -p -r1.300 ldlang.c
--- ld/ldlang.c	16 Feb 2009 07:25:52 -0000	1.300
+++ ld/ldlang.c	16 Feb 2009 07:59:12 -0000
@@ -3438,7 +3438,10 @@ process_insert_statements (void)
 	{
 	  /* Keep pointers to the first and last output section
 	     statement in the sequence we may be about to move.  */
-	  last_os = &(*s)->output_section_statement;
+	  os = &(*s)->output_section_statement;
+
+	  ASSERT (last_os == NULL || last_os->next == os);
+	  last_os = os;
 
 	  /* Set constraint negative so that lang_output_section_find
 	     won't match this output section statement.  At this

-- 
Alan Modra
Australia Development Lab, IBM