linker relaxation

linker relaxation

[naga raj]

Hi,

   I am using Xilinx Microblaze target with Binutils version 2.21.

   My issue is that after compiler generates assembly instructions,
linker is relaxing few of the instruction and up to this part it is
fine.
   But my linker is not decreasing relaxed instructions space as a
result debug_loc locations in the dwarf2 debugging information is
displaying  the address ranges that are generated by compiler.
   So due to this my debugging information is getting corrupted with
wrong addresses.

   I know this is a known issue in linker relaxation, but as a newbie
to binutils I could not figure it out where to change in my code.


  Please help in resolving this issue. Please point me to any material
or existing port(patch).


Thanks in advance
Nagaraju

Re: linker relaxation

[Nick Clifton]

Hi Nagaraju,

>     But my linker is not decreasing relaxed instructions space as a
> result debug_loc locations in the dwarf2 debugging information is
> displaying the address ranges that are generated by compiler.

>     I know this is a known issue in linker relaxation, but as a newbie
> to binutils I could not figure it out where to change in my code.

The most likely place is: 
bfd/elf32-microblaze.c:microblaze_elf_relax_section().

It is also possible that the DWARF debug_loc address ranges are being 
computed by the assembler, rather than the linker.  Hence they are fixed 
before relaxation occurs and so cannot be corrected by the linker.  Have 
a look at gas/config/tc-mn10300.c:
mn10300_allow_local_subtract() for an example of port that has this 
problem and how it was fixed there.

Cheers
   Nick

Re: linker relaxation

[naga raj]

Hi Nick,

   Thanks for the reply. I will look in to it.

On Wed, Jun 22, 2011 at 8:02 PM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Nagaraju,
>
>>    But my linker is not decreasing relaxed instructions space as a
>> result debug_loc locations in the dwarf2 debugging information is
>> displaying the address ranges that are generated by compiler.
>
>>    I know this is a known issue in linker relaxation, but as a newbie
>> to binutils I could not figure it out where to change in my code.
>
> The most likely place is:
> bfd/elf32-microblaze.c:microblaze_elf_relax_section().
>
> It is also possible that the DWARF debug_loc address ranges are being
> computed by the assembler, rather than the linker.  Hence they are fixed
> before relaxation occurs and so cannot be corrected by the linker.  Have a
> look at gas/config/tc-mn10300.c:
> mn10300_allow_local_subtract() for an example of port that has this problem
> and how it was fixed there.
>
> Cheers
>  Nick
>
>

Thanks,
Nagaraju

Re: linker relaxation

[Edgar E. Iglesias]

On Wed, Jun 22, 2011 at 10:28:32AM +0530, naga raj wrote:
> Hi,
> 
>    I am using Xilinx Microblaze target with Binutils version 2.21.
> 
>    My issue is that after compiler generates assembly instructions,
> linker is relaxing few of the instruction and up to this part it is
> fine.
>    But my linker is not decreasing relaxed instructions space as a
> result debug_loc locations in the dwarf2 debugging information is
> displaying  the address ranges that are generated by compiler.
>    So due to this my debugging information is getting corrupted with
> wrong addresses.
> 
>    I know this is a known issue in linker relaxation, but as a newbie
> to binutils I could not figure it out where to change in my code.
> 
> 
>   Please help in resolving this issue. Please point me to any material
> or existing port(patch).

Hi,

I've seen similar errors before. IIRC, the microblaze relax pass in
binutils is broken (in the way you say) but I recall only seeing this
with bare-metal toolchains. It turned out that GCC, when built for
linux targets, turns off linker relaxation. I figured it was due to
the relax bugs. I dont remember all the details now though, so I might
be wrong.

Cheers

Re: linker relaxation

[Michael Eager]

On 06/23/2011 05:35 PM, Edgar E. Iglesias wrote:

> I've seen similar errors before. IIRC, the microblaze relax pass in
> binutils is broken (in the way you say) but I recall only seeing this
> with bare-metal toolchains. It turned out that GCC, when built for
> linux targets, turns off linker relaxation. I figured it was due to
> the relax bugs. I dont remember all the details now though, so I might
> be wrong.

Do you recall which version of binutils had this problem?


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: linker relaxation

[Edgar E. Iglesias]

On Thu, Jun 23, 2011 at 06:03:04PM -0700, Michael Eager wrote:
> On 06/23/2011 05:35 PM, Edgar E. Iglesias wrote:
> 
> > I've seen similar errors before. IIRC, the microblaze relax pass in
> > binutils is broken (in the way you say) but I recall only seeing this
> > with bare-metal toolchains. It turned out that GCC, when built for
> > linux targets, turns off linker relaxation. I figured it was due to
> > the relax bugs. I dont remember all the details now though, so I might
> > be wrong.
> 
> Do you recall which version of binutils had this problem?

I think I saw it with 2.16.1 and with cvs checkout from about
a year ago, maybe less.

Cheers

Linker relaxation

[Stephane Carrez]

Hi!

I would like to implement linker relaxation for some instructions of
68HC11/68HC12. I remember there was some discussions about that for m68K
(in April 17th, 2000), and I have some questions:

 o Existing targets are using specific relocations (.rel or .rela)
   to specify the relaxation points.  Some time ago there was a discussion
   that it would be more appropriate to use a specific section to
   store those relaxation information.

   So, what is the recommended way to store the relaxation relocs?

   (As far as I'm concerned, using relocs is easier, but well, I don't care)

 o If a specific section is dedicated to that, would it make sense to
   also take into account the GNU_VTINHERIT/VTENTRY within it?

 o Now, the hard question about gas -gdwarf2....

   Suppose you have an instruction that is linker-relaxable, and that
   you assembled the source with -gdwarf2.  In that case, Gas generated
   .debug_* sections that gives debugging info, and in particular the
   size of that insn.  If that instruction is shrunk, how can the debugging
   information be fixed?

   My understanding of gas/dwarf2dbg.c is that nothing is there to emit
   a relaxation info for an instruction that can be linker-relaxable.
   The difference with the instruction-relaxation is that the fix/correction
   must be made in the .debug_line.

Thanks,
  Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France