This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC 00/13] MIPS64 support


On 08/01/2014 02:15 PM, Mark Wielaard wrote:
>> Apparently -msym32 also affects the FDE data for unwind support. It's not
>> clear how to detect it cleanly in there. Apparently an "address_size" field
>> can be included in the CIE, but I don't have it. Both eu-readelf and
>> binutils readelf show corrupt FDEs. Patches 12 and 13 are evil hacks.
>> Presumably I could try to interpret initial_address both ways and attempt
>> to lookup the CU?
> 
> Do you have an example ELF/DWARF file that shows this issue?

I attached lib/sort.o from linux ~3.10 compiled for mips64. It's small but shows the issues involved.

The header says ELF64:

ELF Header:
  Magic:   7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           MIPS R3000

However the compilation unit has a pointer size of 4:

  Compilation Unit @ offset 0x0:
   Length:        0x142e (32-bit)
   Version:       2
   Abbrev Offset: 0x0
   Pointer Size:  4

The CIE/FDE data has no address size data so the FDEs are interpreted as 64bit. Here's what binutils readelf shows:

00000000 000000000000000c ffffffff CIE
  Version:               1
  Augmentation:          ""
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 31
  DW_CFA_def_cfa: r29 ofs 0
00000010 000000000000000c 00000000 FDE cie=00000000 pc=0000000000000014..0000000c00000014
00000020 000000000000000c 00000000 FDE cie=00000000 pc=0000001400000028..0000003c00000028
00000030 0000000000000028 00000000 FDE cie=00000000 pc=0000003c00000200..480e803d4897089e
  DW_CFA_advance_loc4: 1217727048 to 0000003c48950c48
  DW_CFA_offset: r19 at cfa-56
  DW_CFA_advance_loc: 32 to 0000003c48950c68
  DW_CFA_offset: r16 at cfa-80
  DW_CFA_offset: r17 at cfa-72
  DW_CFA_offset: r18 at cfa-64
  DW_CFA_offset: r20 at cfa-48
  DW_CFA_offset: r22 at cfa-32
  DW_CFA_offset: r31 at cfa-8

It's pretty clear that FDE data makes much more sense if you interpret the initial_address and address_range as 32bit. Here's what I get with a hacked version of eu-readelf which interprets all FDE data as 32bit:

DWARF section [17] '.debug_frame' at offset 0x1d88:
hack ptr_size=4
 [     0] CIE length=12
   CIE_id:                   18446744073709551615
   version:                  1
   augmentation:             ""
   code_alignment_factor:    1
   data_alignment_factor:    -4
   return_address_register:  31
   Program:
     def_cfa r29 (reg29) at offset 0
 [    10] FDE length=12 cie=[     0]
   CIE_pointer:              0
   initial_location:         .text+0000000000 <u32_swap>
   address_range:            0x14
   Program:
 [    20] FDE length=12 cie=[     0]
   CIE_pointer:              0
   initial_location:         .text+0x00000014 <generic_swap>
   address_range:            0x28
   Program:
 [    30] FDE length=40 cie=[     0]
   CIE_pointer:              0
   initial_location:         .text+0x0000003c <sort>
   address_range:            0x200
   Program:
     advance_loc 8 to 0x8
     def_cfa_offset 128
     advance_loc 8 to 0x10
     offset r23 (reg23) at cfa-24
     offset r30 (reg30) at cfa-16
     advance_loc 8 to 0x18
     offset r21 (reg21) at cfa-40
     advance_loc 8 to 0x20
     offset r19 (reg19) at cfa-56
     advance_loc 32 to 0x40
     offset r16 (reg16) at cfa-80
     offset r17 (reg17) at cfa-72
     offset r18 (reg18) at cfa-64
     offset r20 (reg20) at cfa-48
     offset r22 (reg22) at cfa-32
     offset r31 (reg31) at cfa-8

This file also shows structs with DW_op_constu data_member_locations:

 <1><54>: Abbrev Number: 8 (DW_TAG_structure_type)
    <55>   DW_AT_name        : (indirect string, offset: 0x873): kernel_symbol
    <59>   DW_AT_byte_size   : 16
    <5a>   DW_AT_decl_file   : 2
    <5b>   DW_AT_decl_line   : 27
    <5c>   DW_AT_sibling     : <0x7d>
 <2><60>: Abbrev Number: 9 (DW_TAG_member)
    <61>   DW_AT_name        : (indirect string, offset: 0x311): value
    <65>   DW_AT_decl_file   : 2
    <66>   DW_AT_decl_line   : 28
    <67>   DW_AT_type        : <0x21>
    <6b>   DW_AT_data_member_location: 2 byte block: 10 0 	(DW_OP_constu: 0)
 <2><6e>: Abbrev Number: 9 (DW_TAG_member)
    <6f>   DW_AT_name        : (indirect string, offset: 0x846): name
    <73>   DW_AT_decl_file   : 2
    <74>   DW_AT_decl_line   : 29
    <75>   DW_AT_type        : <0x3b>
    <79>   DW_AT_data_member_location: 2 byte block: 10 8 	(DW_OP_constu: 8)

Regards,
Leonard

Attachment: sort.o
Description: application/object


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]