public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: FW: dwarf2 error(microblaze)
       [not found] <4c3a277c-f2cf-4c8d-9f8f-1ed8c9b8b136@VA3EHSMHS015.ehs.local>
@ 2011-06-10  6:48 ` Michael Eager
  2011-06-22 15:43   ` naga raj
  0 siblings, 1 reply; 4+ messages in thread
From: Michael Eager @ 2011-06-10  6:48 UTC (permalink / raw)
  To: Nagaraju Mekala; +Cc: gcc-help

On 06/09/2011 01:47 AM, Nagaraju Mekala wrote:

>   I have compiled memorytest.c with default options using Gcc-4.6.0 as you suggested.
>
>    DWARF of  main(),i and location list referenced are:
>
>    <1><47a>: Abbrev Number: 13 (DW_TAG_subprogram)
>      <47b>    DW_AT_external    : 1
>      <47c>    DW_AT_name        : (indirect string, offset: 0xf4): main
>      <480>    DW_AT_decl_file   : 1
>      <481>    DW_AT_decl_line   : 59
>      <482>    DW_AT_type        :<0x390>
>      <486>    DW_AT_low_pc      : 0x3dc
>      <48a>    DW_AT_high_pc     : 0x490
>      <48e>    DW_AT_frame_base  : 0x2c    (location list)
>      <492>    DW_AT_sibling     :<0x4a3>
>   <2><496>: Abbrev Number: 14 (DW_TAG_variable)
>      <497>    DW_AT_name        : i
>      <499>    DW_AT_decl_file   : 1
>      <49a>    DW_AT_decl_line   : 61
>      <49b>    DW_AT_type        :<0x390>
>      <49f>    DW_AT_location    : 2 byte block: 91 78     (DW_OP_fbreg: -8)
>
> Contents of the .debug_loc section:
>
>      Offset   Begin    End      Expression
>      00000000 000001e4 000001e8 (DW_OP_breg1 (r1): 0)
>      00000000 000001e8 000001f4 (DW_OP_breg1 (r1): 36)
>      00000000 000001f4 0000048c (DW_OP_breg19 (r19): 36)
>      00000000<End of list>
>      0000002c 0000048c 00000490 (DW_OP_breg1 (r1): 0)
>      0000002c 00000490 0000049c (DW_OP_breg1 (r1): 36)
>      0000002c 0000049c 00000570 (DW_OP_breg19 (r19): 36)
>      0000002c<End of list>
>
>
>     According to my observation .debug_loc at 0000002c Begin location should be 000003dc for main but it is 0000048c is this correct??

Yes.

If you have compiled with -g -O0, the first few instructions for main
should be something like this to set up r19 as the frame pointer:

000003dc <main>:
  3dc:   3021ffe0        addik   r1, r1, -32
  3e0:   f9e10000        swi     r15, r1, 0
  3e4:   fa61001c        swi     r19, r1, 28
  3e8:   12610000        addk    r19, r1, r0

You can verify this with mb-objdump -d.

The assembly code for main should look something like this:

        .globl  main
$LFB1:
$LM3:
         .ent    main
         .type   main, @function
main:
         .frame  r19,32,r15              # vars= 0, regs= 1, args= 24
         .mask   0x00088000

         addik   r1,r1,-32
$LCFI3:
         swi     r15,r1,0
$LCFI4:
         swi     r19,r1,28
$LCFI5:
         addk    r19,r1,r0
$LCFI6:

The second entry in .debug_loc should start with this:

$LLST1:
         .4byte  $LFB1-$Ltext0
         .4byte  $LCFI3-$Ltext0
         .2byte  0x2
         .byte   0x71

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: FW: dwarf2 error(microblaze)
  2011-06-10  6:48 ` FW: dwarf2 error(microblaze) Michael Eager
@ 2011-06-22 15:43   ` naga raj
  2011-06-22 21:17     ` Michael Eager
  0 siblings, 1 reply; 4+ messages in thread
From: naga raj @ 2011-06-22 15:43 UTC (permalink / raw)
  To: Michael Eager, Ian Lance Taylor; +Cc: gcc-help

On Fri, Jun 10, 2011 at 4:41 AM, Michael Eager <eager@eagerm.com> wrote:
> On 06/09/2011 01:47 AM, Nagaraju Mekala wrote:
>
>>  I have compiled memorytest.c with default options using Gcc-4.6.0 as you
>> suggested.
>>
>>   DWARF of  main(),i and location list referenced are:
>>
>>   <1><47a>: Abbrev Number: 13 (DW_TAG_subprogram)
>>     <47b>    DW_AT_external    : 1
>>     <47c>    DW_AT_name        : (indirect string, offset: 0xf4): main
>>     <480>    DW_AT_decl_file   : 1
>>     <481>    DW_AT_decl_line   : 59
>>     <482>    DW_AT_type        :<0x390>
>>     <486>    DW_AT_low_pc      : 0x3dc
>>     <48a>    DW_AT_high_pc     : 0x490
>>     <48e>    DW_AT_frame_base  : 0x2c    (location list)
>>     <492>    DW_AT_sibling     :<0x4a3>
>>  <2><496>: Abbrev Number: 14 (DW_TAG_variable)
>>     <497>    DW_AT_name        : i
>>     <499>    DW_AT_decl_file   : 1
>>     <49a>    DW_AT_decl_line   : 61
>>     <49b>    DW_AT_type        :<0x390>
>>     <49f>    DW_AT_location    : 2 byte block: 91 78     (DW_OP_fbreg: -8)
>>
>> Contents of the .debug_loc section:
>>
>>     Offset   Begin    End      Expression
>>     00000000 000001e4 000001e8 (DW_OP_breg1 (r1): 0)
>>     00000000 000001e8 000001f4 (DW_OP_breg1 (r1): 36)
>>     00000000 000001f4 0000048c (DW_OP_breg19 (r19): 36)
>>     00000000<End of list>
>>     0000002c 0000048c 00000490 (DW_OP_breg1 (r1): 0)
>>     0000002c 00000490 0000049c (DW_OP_breg1 (r1): 36)
>>     0000002c 0000049c 00000570 (DW_OP_breg19 (r19): 36)
>>     0000002c<End of list>
>>
>>
>>    According to my observation .debug_loc at 0000002c Begin location
>> should be 000003dc for main but it is 0000048c is this correct??
>
> Yes.
>
> If you have compiled with -g -O0, the first few instructions for main
> should be something like this to set up r19 as the frame pointer:
>
> 000003dc <main>:
>  3dc:   3021ffe0        addik   r1, r1, -32
>  3e0:   f9e10000        swi     r15, r1, 0
>  3e4:   fa61001c        swi     r19, r1, 28
>  3e8:   12610000        addk    r19, r1, r0
>
> You can verify this with mb-objdump -d.
>
> The assembly code for main should look something like this:
>
>       .globl  main
> $LFB1:
> $LM3:
>        .ent    main
>        .type   main, @function
> main:
>        .frame  r19,32,r15              # vars= 0, regs= 1, args= 24
>        .mask   0x00088000
>
>        addik   r1,r1,-32
> $LCFI3:
>        swi     r15,r1,0
> $LCFI4:
>        swi     r19,r1,28
> $LCFI5:
>        addk    r19,r1,r0
> $LCFI6:
>
> The second entry in .debug_loc should start with this:
>
> $LLST1:
>        .4byte  $LFB1-$Ltext0
>        .4byte  $LCFI3-$Ltext0
>        .2byte  0x2
>        .byte   0x71
>

Investigating the same issue further. I found that issue is in linker.

  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(including relaxed instruction spaces).
  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.

  I am using Xilinx Microblaze target with Binutils version 2.21.

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


Thanks,
Nagaraju

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: FW: dwarf2 error(microblaze)
  2011-06-22 15:43   ` naga raj
@ 2011-06-22 21:17     ` Michael Eager
  2011-06-23 12:16       ` naga raj
  0 siblings, 1 reply; 4+ messages in thread
From: Michael Eager @ 2011-06-22 21:17 UTC (permalink / raw)
  To: naga raj; +Cc: gcc-help

On 06/22/2011 05:13 AM, naga raj wrote:

> Investigating the same issue further. I found that issue is in linker.
>
>    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(including relaxed instruction spaces).
>    So due to this my debugging information is getting corrupted with
> wrong addresses.

Sounds like a possible cause.

>    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.

What known issue?

>    I am using Xilinx Microblaze target with Binutils version 2.21.
>
>   Please help in resolving this issue. Please point me to any material
> or existing port(patch).

There's no existing patch; this appears to be a new problem.

The relaxation code is in binutils/bfd/elf32-microblaze.c in
microblaze_elf_relax_section().  You will need to find out if
it isn't handling the relocations correctly, not moving code
correctly, incorrectly adjusting the fixup value, or perhaps
some other reason why the relaxed address is computed incorrectly.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: FW: dwarf2 error(microblaze)
  2011-06-22 21:17     ` Michael Eager
@ 2011-06-23 12:16       ` naga raj
  0 siblings, 0 replies; 4+ messages in thread
From: naga raj @ 2011-06-23 12:16 UTC (permalink / raw)
  To: Michael Eager; +Cc: gcc-help

Hi Mike

On Wed, Jun 22, 2011 at 8:38 PM, Michael Eager <eager@eagerm.com> wrote:
> On 06/22/2011 05:13 AM, naga raj wrote:
>
>> Investigating the same issue further. I found that issue is in linker.
>>
>>   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(including relaxed instruction spaces).
>>   So due to this my debugging information is getting corrupted with
>> wrong addresses.
>
> Sounds like a possible cause.
>
>>   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.
>
> What known issue?
>
>>   I am using Xilinx Microblaze target with Binutils version 2.21.
>>
>>  Please help in resolving this issue. Please point me to any material
>> or existing port(patch).
>
> There's no existing patch; this appears to be a new problem.
>
> The relaxation code is in binutils/bfd/elf32-microblaze.c in
> microblaze_elf_relax_section().  You will need to find out if
> it isn't handling the relocations correctly, not moving code
> correctly, incorrectly adjusting the fixup value, or perhaps
> some other reason why the relaxed address is computed incorrectly.

Thanks for information. I will look in to it and get back to you if required.
> --
> Michael Eager    eager@eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
>

Thanks
Nagaraju

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-06-23 10:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <4c3a277c-f2cf-4c8d-9f8f-1ed8c9b8b136@VA3EHSMHS015.ehs.local>
2011-06-10  6:48 ` FW: dwarf2 error(microblaze) Michael Eager
2011-06-22 15:43   ` naga raj
2011-06-22 21:17     ` Michael Eager
2011-06-23 12:16       ` naga raj

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).