search

davea42 / libdwarf-code

Contains source for libdwarf, a library for reading DWARF2 and later DWARF. Contains source to create dwarfdump, a program which prints DWARF2 and later DWARF in readable format. Has a very limited DWARF writer set of functions in libdwarfp (producer library). Builds using GNU configure, meson, or cmake.
Other
168 stars 69 forks source link

Issue with range handling for gcc 10's dwarf 4 split-dwarf output #265

Open jeremy-rifkin opened 1 week ago

jeremy-rifkin commented 1 week ago

Hi, I'm seeing a discrepancy between ranges reported by libdwarf's dwarfdump and llvm's dwarfdump for a subprogram DIE:

Llvm dwarfdump:

0x0008722c:   DW_TAG_subprogram
                DW_AT_external  (true)
                DW_AT_name  ("stacktrace_basic")
                DW_AT_decl_file (0x07)
                DW_AT_decl_line (27)
                DW_AT_decl_column   (31)
                DW_AT_linkage_name  ("_Z16stacktrace_basicv")
                DW_AT_ranges    (0x00022030
                   [0x000000000002d400, 0x000000000002df68)
                   [0x000000000000e94d, 0x000000000000ea14))
                DW_AT_frame_base    (DW_OP_call_frame_cfa)
                DW_AT_GNU_all_tail_call_sites   (true)
                DW_AT_sibling   (0x0008e081)

Libdwarf dwarfump:

< 1><0x0008722c GOFF=0x0008722c>    DW_TAG_subprogram <abbrev 399 ABGOFF = 0x00001eeb count = 0x0000000a>
                                      DW_AT_external              yes(1) <form DW_FORM_flag_present 25>
                                      DW_AT_name                  (indexed string: 0x000013ef)stacktrace_basic <form DW_FORM_GNU_str_index 7938>
                                      DW_AT_decl_file             0x00000007 <form DW_FORM_data1 11>
                                      DW_AT_decl_line             0x0000001b <form DW_FORM_data1 11>
                                      DW_AT_decl_column           0x0000001f <form DW_FORM_data1 11>
                                      DW_AT_linkage_name          (indexed string: 0x000008be)_Z16stacktrace_basicv <form DW_FORM_GNU_str_index 7938>
                                      DW_AT_ranges                0x00022030 <form DW_FORM_sec_offset 23>
  ranges: 3 at .debug_ranges offset 139312 (0x00022030)  ( base addr 0x00000000) (48 bytes)
   [ 0] range entry  raw: 0x00022044,  0x0002205b cooked: 0x00022044,  0x0002205b
   [ 1] range entry  raw: 0x0002205b,  0x00022075 cooked: 0x0002205b,  0x00022075
   [ 2] range end    0,0
                                      DW_AT_frame_base            len 0x0001: 0x9c:  <form DW_FORM_exprloc 24>
                                          DW_OP_call_frame_cfa
                                      DW_AT_GNU_all_tail_call_sites yes(1) <form DW_FORM_flag_present 25>
                                      DW_AT_sibling               <0x0008e081 GOFF=0x0008e081> <form DW_FORM_ref4 19>

The output from llvm dwarfdump is what I expect and I believe it to be correct in this case.

Here are the relevant objects: br.zip

Llvm command: llvm-dwarfdump-18 unittest --dwo

Dwarfdump command: dwarfdump -i -M -G -vv --file-tied=unittest test/CMakeFiles/unittest.dir/unit/stacktrace.cpp.dwo

I came across this while testing recent versions of libdwarf with my library, the specific code I'm testing on my library is https://github.com/jeremy-rifkin/cpptrace/commit/1c9d22344b64ed0442d1e44b60ae80d89b395930.

The specific configurations showing failures are:

| compiler   | stdlib    | sanitizers | build_type     | shared | has_dl_find_object | split_dwarf | dwarf_version |
| g++-10     | libstdc++ | OFF        | RelWithDebInfo | OFF    | OFF                | ON          | 4             |
| g++-10     | libstdc++ | OFF        | RelWithDebInfo | OFF    | ON                 | ON          | 4             |
| g++-10     | libstdc++ | OFF        | RelWithDebInfo | ON     | OFF                | ON          | 4             |
| g++-10     | libstdc++ | OFF        | RelWithDebInfo | ON     | ON                 | ON          | 4             |
| g++-10     | libstdc++ | ON         | RelWithDebInfo | OFF    | OFF                | ON          | 4             |
| g++-10     | libstdc++ | ON         | RelWithDebInfo | OFF    | ON                 | ON          | 4             |
| g++-10     | libstdc++ | ON         | RelWithDebInfo | ON     | OFF                | ON          | 4             |
| g++-10     | libstdc++ | ON         | RelWithDebInfo | ON     | ON                 | ON          | 4             |
| clang++-18 | libstdc++ | OFF        | Debug          | OFF    | OFF                | ON          | 5             |
| clang++-18 | libstdc++ | OFF        | Debug          | OFF    | ON                 | ON          | 5             |
| clang++-18 | libstdc++ | OFF        | Debug          | ON     | OFF                | ON          | 5             |
| clang++-18 | libstdc++ | OFF        | Debug          | ON     | ON                 | ON          | 5             |
| clang++-18 | libstdc++ | OFF        | RelWithDebInfo | OFF    | OFF                | ON          | 5             |
| clang++-18 | libstdc++ | OFF        | RelWithDebInfo | OFF    | ON                 | ON          | 5             |
| clang++-18 | libstdc++ | OFF        | RelWithDebInfo | ON     | OFF                | ON          | 5             |
| clang++-18 | libstdc++ | OFF        | RelWithDebInfo | ON     | ON                 | ON          | 5             |

I haven't yet looked into the clang configurations that are failing.

jeremy-rifkin commented 1 week ago

Looks like a similar sort of discrepancy on the clang side:

0x0000ce68:   DW_TAG_subprogram
                DW_AT_ranges    (indexed (0x3) rangelist = 0x000001fb
                   [0x00000000000246f0, 0x0000000000024da2))
                DW_AT_frame_base    (DW_OP_reg6 RBP)
                DW_AT_linkage_name  ("_Z16stacktrace_basicv")
                DW_AT_name  ("stacktrace_basic")
                DW_AT_decl_file (0x01)
                DW_AT_decl_line (27)
                DW_AT_external  (true)
CU Name = (indexed string: 0x00000aff)/mnt/c/Users/rifkin/home/projects/cpptrace/test/unit/stacktrace.cpp
CU Producer = (indexed string: 0x00000afe)Ubuntu clang version 18.1.3 (1ubuntu1)
DIE OFF = 0x0000ce68 GOFF = 0x0000ce68, Low PC = 0x00022ec0, High PC = 0x00022fb4
DW_AT_ranges                <index to debug_rnglists 0x00000003> <form DW_FORM_rnglistx 35>
                                      DW_AT_frame_base            len 0x0001: 0x56:  <form DW_FORM_exprloc 24>
                                          DW_OP_reg6
                                      DW_AT_linkage_name          (indexed string: 0x000008f4)_Z16stacktrace_basicv <form DW_FORM_strx2 38>
                                      DW_AT_name                  (indexed string: 0x000008f5)stacktrace_basic <form DW_FORM_strx2 38>
                                      DW_AT_decl_file             0x00000001 <form DW_FORM_data1 11>
                                      DW_AT_decl_line             0x0000001b <form DW_FORM_data1 11>
                                      DW_AT_external              yes(1) <form DW_FORM_flag_present 25>
davea42 commented 1 week ago

I assume it is the DW_AT_ranges values that are in question, but I'm unsure.

I've been trying to build llvm 18 and, so far failing utterly. Even an initial step of cmake -DCMAKE_BUILD_TYPE=Release /home/downloads/llvm-18.1.8.src utterly fails, missing things. Perhaps the source tree setup is incorrect:

cmake -DCMAKE_BUILD_TYPE=Release $HOME/downloads/llvm-18.1.8.src
jeremy-rifkin commented 1 week ago

Correct, the differing DW_AT_ranges values seem to be causing errors in stack trace resolution for my library. For llvm dwarfdump, I don't think it's anything special about llvm 18 that's just what I happen to have setup locally. I can check with other versions if it would be helpful.

davea42 commented 1 week ago

So please show me a relevant example of llvm-dwarfdump output for an example part of DW_AT_ranges content. I can see all the relevant parts of the dwo and the tied-file (independently and together) so I am hoping sone llvm-dwarfdump output will show such.

davea42 commented 1 week ago

The example you showed above has DW_AT_dwo_id of 3ebed0ea4fd39f55

jeremy-rifkin commented 1 week ago

I don't seem to have the 3ebed0ea4fd39f55 object around anymore but here's the relevant info for what I sent in the zip archive above which has dwo id 559fd34fead0be3e:

unittest:       file format elf64-x86-64

.debug_info contents:
0x00000000: Compile Unit: length = 0x00000030, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000034)

...

0x00000073: DW_TAG_compile_unit
              DW_AT_ranges      (0x00061990
                 [0x000000000002a1a0, 0x000000000003006a)
                 [0x000000000000e4e3, 0x000000000000ed32)
                 [0x000000000001ec90, 0x000000000001ec97)
                 ...
                 [0x000000000001a9a0, 0x000000000001a9a9))
              DW_AT_low_pc      (0x0000000000000000)
              DW_AT_stmt_list   (0x0001e44e)
              DW_AT_GNU_dwo_name        ("test/CMakeFiles/unittest.dir/unit/stacktrace.cpp.dwo")
              DW_AT_comp_dir    ("/mnt/c/Users/rifkin/home/projects/cpptrace/build")
              DW_AT_GNU_pubnames        (true)
              DW_AT_GNU_addr_base       (0x000249c8)
              DW_AT_GNU_dwo_id  (0x559fd34fead0be3e)
              DW_AT_GNU_ranges_base     (0x00033b70)
0x0000009c: Compile Unit: length = 0x00000030, format = DWARF32, version = 0x0004, abbr_offset = 0x0057, addr_size = 0x08 (next unit at 0x000000d0)
test/CMakeFiles/unittest.dir/unit/stacktrace.cpp.dwo:   file format elf64-x86-64

.debug_info.dwo contents:
0x00000000: Compile Unit: length = 0x0009838d, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00098391)

0x0000000b: DW_TAG_compile_unit
              DW_AT_producer    ("GNU C++17 10.5.0 -mtune=generic -march=x86-64 -g -g -gsplit-dwarf -gdwarf-4 -O2 -std=gnu++2a -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection")
              DW_AT_language    (DW_LANG_C_plus_plus)
              DW_AT_name        ("/mnt/c/Users/rifkin/home/projects/cpptrace/test/unit/stacktrace.cpp")
              DW_AT_comp_dir    ("/mnt/c/Users/rifkin/home/projects/cpptrace/build")
              DW_AT_GNU_dwo_id  (0x559fd34fead0be3e)

...

0x0008722c:   DW_TAG_subprogram
                DW_AT_external  (true)
                DW_AT_name      ("stacktrace_basic")
                DW_AT_decl_file (0x07)
                DW_AT_decl_line (27)
                DW_AT_decl_column       (31)
                DW_AT_linkage_name      ("_Z16stacktrace_basicv")
                DW_AT_ranges    (0x00022030
                   [0x000000000002d400, 0x000000000002df68)
                   [0x000000000000e94d, 0x000000000000ea14))
                DW_AT_frame_base        (DW_OP_call_frame_cfa)
                DW_AT_GNU_all_tail_call_sites   (true)
                DW_AT_sibling   (0x0008e081)

The relevant part of the ranges section:

llvm-dwarfdump-18 unittest --debug-ranges | grep 00022030
00022030 0000000000022044 000000000002205b
00022030 000000000002205b 0000000000022075
00022030 <End of list>
davea42 commented 1 week ago

Having looked closely at the CU_DIE and attributes for all three case:

unittest by itself stacktrace.cpp.dwo by itself stacktrace.cpp.dwo with tied unittest

I am not finding anything incorrect or nonsensical.

I just noticed you have new objects. I don't know how to access them. br.zip is the earlier ones. I seen to be stuck untill I can get the relevant data from dwarfdump too.

davea42 commented 1 week ago

"I don't seem to have the 3ebed0ea4fd39f55 object around anymore "

Yes you do, it is in br.zip , link in this issue. yesterday evening I completely forgot how useful that is.

davea42 commented 1 week ago

Since the br.zip has the test object I hope you can provide the ranges data from llvm-dwarfdump that dwarfdump/libdwarf gets wrong. I just need to see what llvm does different from dwarfdump in the case of ranges content. On a single DIE would be adequate. With enough about that DIE so I can recognize it in dwarfdump output.

I suspect I'm not counting a factor in computing a cooked range. Easy to imagine as this is non-standard DWARF4, a GNU extension.

jeremy-rifkin commented 1 week ago

Hi Dave, thanks for the patience. I've re-done the relevant dumps / analyses as follows with the objects from br.zip. I think I understand the confusion, llvm dwarfdump and dwarfdump from this repository are reporting different dwo ids. It actually looks like a simple endianness issue. Relevant info below:

Dump of just unittest by llvm-dwarfdump:

0x00000068: Compile Unit: length = 0x00000030, format = DWARF32, version = 0x0004, abbr_offset = 0x003a, addr_size = 0x08 (next unit at 0x0000009c)

0x00000073: DW_TAG_compile_unit
              DW_AT_ranges  (0x00061990
                 [0x000000000002a1a0, 0x000000000003006a)
                 [0x000000000000e4e3, 0x000000000000ed32)
                 ...
                 [0x0000000000000001, 0x0000000000000001)
                 [0x000000000001a9a0, 0x000000000001a9a9))
              DW_AT_low_pc  (0x0000000000000000)
              DW_AT_stmt_list   (0x0001e44e)
              DW_AT_GNU_dwo_name    ("test/CMakeFiles/unittest.dir/unit/stacktrace.cpp.dwo")
              DW_AT_comp_dir    ("/mnt/c/Users/rifkin/home/projects/cpptrace/build")
              DW_AT_GNU_pubnames    (true)
              DW_AT_GNU_addr_base   (0x000249c8)
              DW_AT_GNU_dwo_id  (0x559fd34fead0be3e)
              DW_AT_GNU_ranges_base (0x00033b70)

Dump of just unittest by dwarfdump from this repository:

CU_HEADER:
  cu_header_length = 0x00000030 48
  version_stamp    = 0x0004     4
  abbrev_offset    = 0x0000003a 58
  address_size     = 0x08       8
  offset_size      = 0x04       4
  cu_type          = 0x04       DW_UT_skeleton
  signature        = 0x3ebed0ea4fd39f55
  typeoffset       = 0x00000000 0

COMPILE_UNIT<header overall offset = 0x00000068>:
< 0><0x0000000b GOFF=0x00000073>  DW_TAG_compile_unit <abbrev 1 ABGOFF = 0x0000003a count = 0x00000009>
                                    DW_AT_ranges                0x00061990 <form DW_FORM_sec_offset 23>
  ranges: 87 at .debug_ranges offset 399760 (0x00061990)  ( base addr 0x00000000) (1392 bytes)
   [ 0] range entry  raw: 0x0002a1a0,  0x0003006a cooked: 0x0002a1a0,  0x0003006a
   [ 1] range entry  raw: 0x0000e4e3,  0x0000ed32 cooked: 0x0000e4e3,  0x0000ed32
   ...
   [84] range entry  raw: 0x00000001,  0x00000001 (empty range) cooked: 0x00000001,  0x00000001
   [85] range entry  raw: 0x0001a9a0,  0x0001a9a9 cooked: 0x0001a9a0,  0x0001a9a9
   [86] range end    0,0
                                    DW_AT_low_pc                0x00000000 <form DW_FORM_addr 1>
                                    DW_AT_stmt_list             0x0001e44e <form DW_FORM_sec_offset 23>
                                    DW_AT_GNU_dwo_name          test/CMakeFiles/unittest.dir/unit/stacktrace.cpp.dwo <form DW_FORM_strp 14>
                                    DW_AT_comp_dir              /mnt/c/Users/rifkin/home/projects/cpptrace/build <form DW_FORM_strp 14>
                                    DW_AT_GNU_pubnames          yes(1) <form DW_FORM_flag_present 25>
                                    DW_AT_GNU_addr_base         0x000249c8 <form DW_FORM_sec_offset 23>
                                    DW_AT_GNU_dwo_id            0x3ebed0ea4fd39f55 <form DW_FORM_data8 7>
                                    DW_AT_GNU_ranges_base       0x00033b70 <form DW_FORM_sec_offset 23>

Dump of header/CU info from stacktrace.cpp.dwo as well as the DIE I'm looking at by llvm dwarfdump (llvm-dwarfdump doesn't have a --file-tied=file like yours, only a --dwo flag requiring the dwo to be in the correct absolute path, but I can get the relevant info):

0x0000000b: DW_TAG_compile_unit
              DW_AT_producer    ("GNU C++17 10.5.0 -mtune=generic -march=x86-64 -g -g -gsplit-dwarf -gdwarf-4 -O2 -std=gnu++2a -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection")
              DW_AT_language    (DW_LANG_C_plus_plus)
              DW_AT_name    ("/mnt/c/Users/rifkin/home/projects/cpptrace/test/unit/stacktrace.cpp")
              DW_AT_comp_dir    ("/mnt/c/Users/rifkin/home/projects/cpptrace/build")
              DW_AT_GNU_dwo_id  (0x559fd34fead0be3e)

0x0008722c:   DW_TAG_subprogram
                DW_AT_external  (true)
                DW_AT_name  ("stacktrace_basic")
                DW_AT_decl_file (0x07)
                DW_AT_decl_line (27)
                DW_AT_decl_column   (31)
                DW_AT_linkage_name  ("_Z16stacktrace_basicv")
                DW_AT_ranges    (0x00022030
                   [0x000000000002d400, 0x000000000002df68)
                   [0x000000000000e94d, 0x000000000000ea14))
                DW_AT_frame_base    (DW_OP_call_frame_cfa)
                DW_AT_GNU_all_tail_call_sites   (true)
                DW_AT_sibling   (0x0008e081)

Dump of header/CU info from stacktrace.cpp.dwo as well as the DIE I'm looking at by dwarfdump from this repository:

CU_HEADER:
  cu_header_length = 0x0009838d 623501
  version_stamp    = 0x0004     4
  abbrev_offset    = 0x00000000 0
  address_size     = 0x08       8
  offset_size      = 0x04       4
  cu_type          = 0x05       DW_UT_split_compile
  signature        = 0x3ebed0ea4fd39f55
  typeoffset       = 0x00000000 0

COMPILE_UNIT<header overall offset = 0x00000000>:
< 0><0x0000000b GOFF=0x0000000b>  DW_TAG_compile_unit <abbrev 304 ABGOFF = 0x0000175c count = 0x00000005>
                                    DW_AT_producer              (indexed string: 0x000021f3)GNU C++17 10.5.0 -mtune=generic -march=x86-64 -g -g -gsplit-dwarf -gdwarf-4 -O2 -std=gnu++2a -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection <form DW_FORM_GNU_str_index 7938>
                                    DW_AT_language              DW_LANG_C_plus_plus <form DW_FORM_data1 11>
                                    DW_AT_name                  (indexed string: 0x000003df)/mnt/c/Users/rifkin/home/projects/cpptrace/test/unit/stacktrace.cpp <form DW_FORM_GNU_str_index 7938>
                                    DW_AT_comp_dir              (indexed string: 0x000006dc)/mnt/c/Users/rifkin/home/projects/cpptrace/build <form DW_FORM_GNU_str_index 7938>
                                    DW_AT_GNU_dwo_id            0x3ebed0ea4fd39f55 <form DW_FORM_data8 7>

< 1><0x0008722c GOFF=0x0008722c>    DW_TAG_subprogram <abbrev 399 ABGOFF = 0x00001eeb count = 0x0000000a>
                                      DW_AT_external              yes(1) <form DW_FORM_flag_present 25>
                                      DW_AT_name                  (indexed string: 0x000013ef)stacktrace_basic <form DW_FORM_GNU_str_index 7938>
                                      DW_AT_decl_file             0x00000007 <form DW_FORM_data1 11>
                                      DW_AT_decl_line             0x0000001b <form DW_FORM_data1 11>
                                      DW_AT_decl_column           0x0000001f <form DW_FORM_data1 11>
                                      DW_AT_linkage_name          (indexed string: 0x000008be)_Z16stacktrace_basicv <form DW_FORM_GNU_str_index 7938>
                                      DW_AT_ranges                0x00022030 <form DW_FORM_sec_offset 23>
  ranges: 3 at .debug_ranges offset 139312 (0x00022030)  ( base addr 0x00000000) (48 bytes)
   [ 0] range entry  raw: 0x00022044,  0x0002205b cooked: 0x00022044,  0x0002205b
   [ 1] range entry  raw: 0x0002205b,  0x00022075 cooked: 0x0002205b,  0x00022075
   [ 2] range end    0,0
                                      DW_AT_frame_base            len 0x0001: 0x9c:  <form DW_FORM_exprloc 24>
                                          DW_OP_call_frame_cfa
                                      DW_AT_GNU_all_tail_call_sites yes(1) <form DW_FORM_flag_present 25>
                                      DW_AT_sibling               <0x0008e081 GOFF=0x0008e081> <form DW_FORM_ref4 19>

Exact steps I performed (mainly for my own memory)

unzip br.zip
cd br
llvm-dwarfdump-18 unittest > unittest-llvm-dump.txt
dwarfdump -i -M -G  -vv unittest > unittest-libdwarf-dump.txt
mkdir -p /mnt/c/Users/rifkin/home/projects/cpptrace/build/test/CMakeFiles/unittest.dir/unit
cp test/CMakeFiles/unittest.dir/unit/stacktrace.cpp.dwo /mnt/c/Users/rifkin/home/projects/cpptrace/build/test/CMakeFiles/unittest.dir/unit
llvm-dwarfdump-18 unittest --dwo > stacktrace-llvm-dump.txt
dwarfdump -i -M -G  -vv --file-tied=unittest test/CMakeFiles/unittest.dir/unit/stacktrace.cpp.dwo > stacktrace-libdwarf-dump.txt
davea42 commented 1 week ago

Well, something odd above I am puzzled about. I added some debug to libdwarf and on the unittest or the stacktrace.cpp.dwo from br.zip so I would be sure to see all signature reads and assigns in libdwarf. I cannot find any dwo_id of 0x559fd34fead0be3e as you show from llvm-dwarfdump ... anywhere.

All I find is

junkdwo:dadebug attrname is DW_AT_GNU_dwo_id
junkdwo:dadebug DW_AT_..   0x3ebed0ea4fd39f55 line 1423
junkdwot:dadebug attrname is DW_AT_GNU_dwo_id
junkdwot:dadebug DW_AT_..   0x3ebed0ea4fd39f55 line 1423
junkdwot:dadebug attrname is DW_AT_GNU_dwo_id
junkdwot:dadebug DW_AT_..   0xeba3efaf51f6ddf1 line 1423
junkdwot:dadebug attrname is DW_AT_GNU_dwo_id
junkdwot:dadebug DW_AT_..   0xe80f6ea416149751 line 1423
junkdwot:dadebug attrname is DW_AT_GNU_dwo_id
junkdwot:dadebug DW_AT_..   0x3ebed0ea4fd39f55 line 1423
junkexe:dadebug attrname is DW_AT_GNU_dwo_id
junkexe:dadebug DW_AT_..   0xeba3efaf51f6ddf1 line 1423
junkexe:dadebug attrname is DW_AT_GNU_dwo_id
junkexe:dadebug DW_AT_..   0xe80f6ea416149751 line 1423
junkexe:dadebug attrname is DW_AT_GNU_dwo_id
junkexe:dadebug DW_AT_..   0x3ebed0ea4fd39f55 line 1423
junkexe:dadebug attrname is DW_AT_GNU_dwo_id
junkexe:dadebug DW_AT_..   0x2454b5c4dc369c8a line 1423
junkexe:dadebug attrname is DW_AT_GNU_dwo_id
junkexe:dadebug DW_AT_..   0x7b7c5ce3c029c83b line 1423
junkexe:dadebug attrname is DW_AT_GNU_dwo_id
junkexe:dadebug DW_AT_..   0xbbf123e6a4ecd9cc line 1423
jeremy-rifkin commented 1 week ago

I think it's just an endianness issue, 559fd34fead0be3e is 3ebed0ea4fd39f55 byteswapped. Not sure whether llvm or libdwarf is right.

davea42 commented 1 week ago

It seems that

https://gardinal.net/forums/topic/how-to-build-llvm-on-linux/

does have some usable llvm build instructions. Of course they don't quite work. For one thing copy-paste results in characters looking like '" (quote) but which are not ascii.. so sh does not recognize as quote.

davea42 commented 1 week ago

While the full build failed on a C++ error message the llvm-dwarfdump Makefile got created, so in that build directory a 'make' seemed to work. I have an executable llvm-dwarfdump.

However I do not get the output you do, and the --dwo option is not named in the --help output,

I can get 

0x0008722c:   DW_TAG_subprogram
                DW_AT_external  (true)
                DW_AT_name  ("stacktrace_basic")
                DW_AT_decl_file (0x07)
                DW_AT_decl_line (27)
                DW_AT_decl_column   (31)
                DW_AT_linkage_name  ("_Z16stacktrace_basicv")
                DW_AT_ranges    (0x00022030)
                DW_AT_frame_base    (DW_OP_call_frame_cfa)
                DW_AT_GNU_all_tail_call_sites   (true)
                DW_AT_sibling   (0x0008e081)

but notice no words about the ranges content here.

Oops, llvm-dwarfdump --version says Ubuntu LLVM version 14.0.0 So the build resulted in... what ubuntu installed, an old llvm-dwarfdump? Oh my.

davea42 commented 1 week ago

So, in the top-of-trunk (latest) build shown on gardinal, It fails for me in SPIRV-LLVM-Translator/lib/SPIRV/SPIRVReader.cpp.

So then do (again in build directory): make llvm-dwarfdump

and it successfully creates llvm-dwarfdump and places in in build/bin

davea42 commented 1 week ago

Running the following:

ll=/home/downloads/llvmclone/llvm/build/bin/llvm-dwarfdump
$ll unittest >junkllexe
$ll --dwo test/CMakeFiles/unittest.dir/unit/stacktrace.cpp.dwo >junklldwo
$ll --dwo  unittest >junklldwot

But llvm-dwarfdump is not expanding DW_AT_ranges.

q3 785: ls -l junkll*
-rw-rw-r-- 1 davea davea  19266223 Oct 11 13:44 junklldwo
-rw-rw-r-- 1 davea davea 154905394 Oct 11 13:44 junklldwot
-rw-rw-r-- 1 davea davea 154905394 Oct 11 13:44 junkllexe

Does not seem to matter where I place the --dwo.

What am I doing wrong?

0x0008722c:   DW_TAG_subprogram 
                DW_AT_external  (true)
                DW_AT_name  ("stacktrace_basic")
                DW_AT_decl_file (0x07)
                DW_AT_decl_line (27)
                DW_AT_decl_column   (31)
                DW_AT_linkage_name  ("_Z16stacktrace_basicv")
                DW_AT_ranges    (0x00022030)
                DW_AT_frame_base    (DW_OP_call_frame_cfa)
                DW_AT_GNU_all_tail_call_sites   (true)
                DW_AT_sibling   (0x0008e081)
davea42 commented 4 days ago

Major computer failure here. Do NOT expect Ubuntu 24.04.1 LTS to work. Be warned. It broke 2 machines Upgrading from 22.04 LTS.

And my major desktop had graphics fail too. Been 3 days on this and don't expect to be fully back in operation for 10 days at least. Ordered one new desktop and recovering via reinstall the working one of the pair.