dwarf2 and linker relaxation problem

dwarf2 and linker relaxation problem

[Dmitry Diky]

Fellows,
I am experiencing some problems with keeping dwarf2 info intact after linker 
relaxation. So, if linker relax section, the line info references are shifted 
by the number of deleted bytes. 
Is there any example which shows how to fix this problem?

Thanks,

Dmitry.

Re: dwarf2 and linker relaxation problem

[Ian Lance Taylor]

Dmitry Diky <ddiky@alarity.com> writes:

> I am experiencing some problems with keeping dwarf2 info intact after linker 
> relaxation. So, if linker relax section, the line info references are shifted 
> by the number of deleted bytes. 
> Is there any example which shows how to fix this problem?

I believe this works on the SH.  See sh_elf_relax_delete_bytes in
elf32-sh.c.

Ian

Re: dwarf2 and linker relaxation problem

[Jim Blandy]

Ian Lance Taylor <ian@airs.com> writes:
> Dmitry Diky <ddiky@alarity.com> writes:
>
>> I am experiencing some problems with keeping dwarf2 info intact after linker 
>> relaxation. So, if linker relax section, the line info references are shifted 
>> by the number of deleted bytes. 
>> Is there any example which shows how to fix this problem?
>
> I believe this works on the SH.  See sh_elf_relax_delete_bytes in
> elf32-sh.c.

Which part of that affects the .debug_line sections?

Re: dwarf2 and linker relaxation problem

[Ian Lance Taylor]

Jim Blandy <jimb@redhat.com> writes:

> Ian Lance Taylor <ian@airs.com> writes:
> > Dmitry Diky <ddiky@alarity.com> writes:
> >
> >> I am experiencing some problems with keeping dwarf2 info intact after linker 
> >> relaxation. So, if linker relax section, the line info references are shifted 
> >> by the number of deleted bytes. 
> >> Is there any example which shows how to fix this problem?
> >
> > I believe this works on the SH.  See sh_elf_relax_delete_bytes in
> > elf32-sh.c.
> 
> Which part of that affects the .debug_line sections?

The part that handles the R_SH_SWITCH* relocs.

Not that I've checked it, but that's the right place to look.

Ian

Re: dwarf2 and linker relaxation problem

[Dmitry Diky]

Ian,

Thanks for this.

> The part that handles the R_SH_SWITCH* relocs.

I checked this twice and it seems that this approach does not work for me.
As I see from .debug_info and .debug_line sections contents they have no 
symbols referenced by .text (for example) section content.
So, the question is - how to hook on 'something' in dw2 sections to adjust 
relaxed references?

Dmitry.

Re: dwarf2 and linker relaxation problem

[Nick Clifton]

Hi Dmitry,

> So, the question is - how to hook on 'something' in dw2 sections to adjust 
> relaxed references?

Why not do what sh_elf_relax_delete_bytes() does ?  Scan through the 
sections attached to the bfd and look for dwarf2 sections which might 
contain references into the relaxed section ?

Cheers
   Nick

Re: dwarf2 and linker relaxation problem

[Dmitry Diky]

Hi Nick,
> Why not do what sh_elf_relax_delete_bytes() does ?  Scan through the
> sections attached to the bfd and look for dwarf2 sections which might
> contain references into the relaxed section ?

Yes, I do this. But it seems that dwarf2 sections do not contain any 
references into relaxed sections. Well, yes, it does contain a reference to 
'.text' , but i cannot find any references to, say, linenumbers.

Cheers,
Dmitry.

Re: dwarf2 and linker relaxation problem

[Dmitry Diky]

Hi Nick,
> Why not do what sh_elf_relax_delete_bytes() does ?  Scan through the
> sections attached to the bfd and look for dwarf2 sections which might
> contain references into the relaxed section ?

Yes, I do this. But it seems that dwarf2 sections do not contain any 
references into relaxed sections. Well, yes, it does contain a reference to 
'.text' , but i cannot find any references to, say, linenumbers.

Cheers,
Dmitry.

Re: dwarf2 and linker relaxation problem

[Nick Clifton]

Hi Dmitry,

> Yes, I do this. But it seems that dwarf2 sections do not contain any 
> references into relaxed sections. Well, yes, it does contain a reference to 
> '.text' , but i cannot find any references to, say, linenumbers.

I think that you may have to parse the contents of the dwarf2 sections 
in order to locate the address-to-linenumber references and then adjust 
them by hand.

Cheers
   Nick

Re: dwarf2 and linker relaxation problem

[Nick Clifton]

Hi Dmitry,

> Yes, I do this. But it seems that dwarf2 sections do not contain any 
> references into relaxed sections. Well, yes, it does contain a reference to 
> '.text' , but i cannot find any references to, say, linenumbers.

I think that you may have to parse the contents of the dwarf2 sections 
in order to locate the address-to-linenumber references and then adjust 
them by hand.

Cheers
   Nick

Re: dwarf2 and linker relaxation problem

[Hans-Peter Nilsson]

On Fri, 2 Sep 2005, Dmitry Diky wrote:
> So, the question is - how to hook on 'something' in dw2 sections to adjust
> relaxed references?

Maybe it's obvious, but I'd check that the assembler doesn't
resolve PC-relative references (i.e. make sure that it emits
relocs for them) when linker relaxation is wanted, for
applicable cases.

brgds, H-P

Re: dwarf2 and linker relaxation problem

[Dmitry Diky]

I do not delete any relocations until linker.
The linker itself does not reloc much in debug sections.
That's why I'm puzzled.

Dmitry.

On Friday 02 September 2005 20:04, Hans-Peter Nilsson wrote:
> On Fri, 2 Sep 2005, Dmitry Diky wrote:
> > So, the question is - how to hook on 'something' in dw2 sections to
> > adjust relaxed references?
>
> Maybe it's obvious, but I'd check that the assembler doesn't
> resolve PC-relative references (i.e. make sure that it emits
> relocs for them) when linker relaxation is wanted, for
> applicable cases.
>
> brgds, H-P

Re: dwarf2 and linker relaxation problem

[Hans-Peter Nilsson]

On Fri, 2 Sep 2005, Dmitry Diky wrote:
> I do not delete any relocations until linker.

I don't know how to put it clearer than with Ian's example.  If
the assembler doesn't emit a relocation for those expressions,
linker relaxation will not work, unless the linker actually
parses the format of the data in that section.

> The linker itself does not reloc much in debug sections.

Seems like a clue that the assembler didn't emit relocations
where it must, for linker relaxation.

brgds, H-P

Re: dwarf2 and linker relaxation problem

[Dmitry Diky]

That's right.

> Seems like a clue that the assembler didn't emit relocations
> where it must, for linker relaxation.

But when I want to emit a debug info for relaxable fragment I just call 
	dwarf2_emit_insn(0);
Then I call frag_var(...), etc.
I do not relax in assembler cause it may be a source of some error and relax 
in linker. In there I adjust any symbols referenced into relaxable sections 
and I do not see any symbols addresses into relaxable section from debug 
section. So then question is: how to force dwarf2 debug info make a footprint 
in debuggable section?

Thanks,
Dmitry.

Re: dwarf2 and linker relaxation problem

[Ian Lance Taylor]

Dmitry Diky <ddiky@alarity.com> writes:

> That's right.
> 
> > Seems like a clue that the assembler didn't emit relocations
> > where it must, for linker relaxation.
> 
> But when I want to emit a debug info for relaxable fragment I just call 
> 	dwarf2_emit_insn(0);
> Then I call frag_var(...), etc.
> I do not relax in assembler cause it may be a source of some error and relax 
> in linker. In there I adjust any symbols referenced into relaxable sections 
> and I do not see any symbols addresses into relaxable section from debug 
> section. So then question is: how to force dwarf2 debug info make a footprint 
> in debuggable section?

Look at gas/tc-sh.[ch].  In particular TC_FORCE_RELOCATION_SUB_LOCAL
and TC_FORCE_RELOCATION_LOCAL.  And in general any use of the global
variable sh_relax.

Ian

Re: dwarf2 and linker relaxation problem

[Richard Henderson]

On Fri, Sep 02, 2005 at 01:09:27PM -0400, Hans-Peter Nilsson wrote:
> Seems like a clue that the assembler didn't emit relocations
> where it must, for linker relaxation.

There are no relocations possible here.  The linker will have to
completely parse and re-emit the .debug_line section, the 
.debug_frame section, and the .eh_frame section.

Which is why several targets do *not* delete instructions during
relaxation, and instead only replace with nops.


r~

Re: dwarf2 and linker relaxation problem

[Ian Lance Taylor]

Richard Henderson <rth@redhat.com> writes:

> On Fri, Sep 02, 2005 at 01:09:27PM -0400, Hans-Peter Nilsson wrote:
> > Seems like a clue that the assembler didn't emit relocations
> > where it must, for linker relaxation.
> 
> There are no relocations possible here.  The linker will have to
> completely parse and re-emit the .debug_line section, the 
> .debug_frame section, and the .eh_frame section.

Well, no, relocations are possible, but you do generally need to
define new relocation types, and you need to force the assembler to
generate them.

SH ELF has nine relocation types which exist only for relaxation
purposes (R_SH_SWITCH8 through R_SH_LABEL).

Ian

Re: dwarf2 and linker relaxation problem

[Dmitry Diky]

Ian,
I have checked sh_elf_relax_delete_bytes() in elf32-sh.c file.
It seems that relaxation does not touch .debug_line section at all, cause 
there are no references from .debug_line section into debuggable .text 
section. Also, as it seems to me, dwarf2 generator does not emit something 
like '.word .l1 - .l2' in executable section suitable for further relocation 
by linker. Am I correct?

Thanks,
Dmitry.

> > There are no relocations possible here.  The linker will have to
> > completely parse and re-emit the .debug_line section, the
> > .debug_frame section, and the .eh_frame section.
>
> Well, no, relocations are possible, but you do generally need to
> define new relocation types, and you need to force the assembler to
> generate them.

Re: dwarf2 and linker relaxation problem

[Ian Lance Taylor]

Dmitry Diky <ddiky@alarity.com> writes:

> > The part that handles the R_SH_SWITCH* relocs.
> 
> I checked this twice and it seems that this approach does not work for me.
> As I see from .debug_info and .debug_line sections contents they have no 
> symbols referenced by .text (for example) section content.
> So, the question is - how to hook on 'something' in dw2 sections to adjust 
> relaxed references?

The SH assembler explicitly emits relocs which are only required for
relaxation.  For example, for
    .word foo - bar
it will emit a reloc, even when the value can be resolved in the
assembler.  This exposes the information to the relaxation code.

Ian

Re: dwarf2 and linker relaxation problem

[Jim Blandy]

Ian Lance Taylor <ian@airs.com> writes:
> Jim Blandy <jimb@redhat.com> writes:
>> Ian Lance Taylor <ian@airs.com> writes:
>> > Dmitry Diky <ddiky@alarity.com> writes:
>> >> I am experiencing some problems with keeping dwarf2 info intact after linker 
>> >> relaxation. So, if linker relax section, the line info references are shifted 
>> >> by the number of deleted bytes. 
>> >> Is there any example which shows how to fix this problem?
>> >
>> > I believe this works on the SH.  See sh_elf_relax_delete_bytes in
>> > elf32-sh.c.
>> 
>> Which part of that affects the .debug_line sections?
>
> The part that handles the R_SH_SWITCH* relocs.
>
> Not that I've checked it, but that's the right place to look.

These days the assembler produces .debug_line sections that use the
Dwarf special opcodes:

    $ readelf -wl bfd/archive.o
    ...
     Line Number Statements:
      Extended opcode 2: set Address to 0x0
      Advance Line by 161 to 162
      Copy
      Special opcode 92: advance Address by 6 to 0x6 and Line by 3 to 165
      Advance PC by constant 17 to 0x17
      Special opcode 62: advance Address by 4 to 0x1b and Line by 1 to 166
      Advance PC by constant 17 to 0x2c
    ...
    $

If the linker changes the length of an instruction between 0 and 6,
say, then that Dwarf special opcode needs to be changed.  I don't see
how any existing SH reloc could be shoehorned into fixing that.  And
then, since the special opcodes only have limited ranges, a relaxation
could require you to switch from a special opcode to something more
general, like a DW_LNS_advance_pc.

This is why, as Richard says, in order to do relaxation in the
presence of modern Dwarf line info, the linker needs to read the line
number info, do the relaxations while adjusting the machine / source
mapping as needed, and then re-emit the line number info.

I didn't see anything to do this in the BFD code --- thus my question.

Re: dwarf2 and linker relaxation problem

[Ian Lance Taylor]

Jim Blandy <jimb@redhat.com> writes:

> These days the assembler produces .debug_line sections that use the
> Dwarf special opcodes:
> 
>     $ readelf -wl bfd/archive.o
>     ...
>      Line Number Statements:
>       Extended opcode 2: set Address to 0x0
>       Advance Line by 161 to 162
>       Copy
>       Special opcode 92: advance Address by 6 to 0x6 and Line by 3 to 165
>       Advance PC by constant 17 to 0x17
>       Special opcode 62: advance Address by 4 to 0x1b and Line by 1 to 166
>       Advance PC by constant 17 to 0x2c
>     ...
>     $
> 
> If the linker changes the length of an instruction between 0 and 6,
> say, then that Dwarf special opcode needs to be changed.  I don't see
> how any existing SH reloc could be shoehorned into fixing that.  And
> then, since the special opcodes only have limited ranges, a relaxation
> could require you to switch from a special opcode to something more
> general, like a DW_LNS_advance_pc.
> 
> This is why, as Richard says, in order to do relaxation in the
> presence of modern Dwarf line info, the linker needs to read the line
> number info, do the relaxations while adjusting the machine / source
> mapping as needed, and then re-emit the line number info.
> 
> I didn't see anything to do this in the BFD code --- thus my question.

I see.  I did forget about those kinds of things.  You're right, this
will require some extra relaxation code to handle DWARF line
information.

Or I suppose one could change the assembler to avoid using the special
opcodes when relaxing, and to always use an absolute address.

Sorry for the misdirection.

Ian

Re: dwarf2 and linker relaxation problem

[Dmitry Diky]

> > presence of modern Dwarf line info, the linker needs to read the line
> > number info, do the relaxations while adjusting the machine / source
> > mapping as needed, and then re-emit the line number info.
> >
> > I didn't see anything to do this in the BFD code --- thus my question.
>

So, it seems tha only one opcode/line advance should be changed in .debug_line 
in case of relaxation. Namely (for my target): 
  Special opcode 35: advance Address by 2 to 0x48140014 and Line by 2 to 18
  Special opcode 35: advance Address by 2 to 0x48140016 and Line by 2 to 20
  Special opcode 90: advance Address by 6 to 0x4814001c and Line by 1 to 21  
<- relaxed insn is here.
  Special opcode 34: advance Address by 2 to 0x4814001e and Line by 1 to 22
  Special opcode 34: advance Address by 2 to 0x48140020 and Line by 1 to 23
 
So, if the code 90 will be changed properly, everything should be Ok. Am I 
correct?

Cheers,
Dmitry.

Re: dwarf2 and linker relaxation problem

[Richard Henderson]

On Wed, Sep 07, 2005 at 10:41:49AM +0400, Dmitry Diky wrote:
>   Special opcode 90: advance Address by 6 to 0x4814001c and Line by 1 to 21  
> <- relaxed insn is here.
>   Special opcode 34: advance Address by 2 to 0x4814001e and Line by 1 to 22
>  
> So, if the code 90 will be changed properly, everything should be Ok. Am I 
> correct?

From your picture I would have expected the following code 34 to change.

As long as the address displacement only decreases during relaxation, 
then you can find a replacement special opcode that will match the new
address displacement and the old line number displacement.

If your relaxation ever adds bytes, then the correction may need to add
new bytes to the .debug_line section to represent the change, at which
point you may have to re-encode the entire section.

If all of this is too difficult, then we can add an internal flag to the
assembler that limits the encoding of .debug_line to DW_LNS_fixed_advance_pc, 
which would involve a fixed length 16-bit displacement; presumably you
have a relocation for that.


r~