search for: end_sequence

...but if "MOV PC, R0" is not a return instruction, I'm guessing that the sequence starting at A39C is a dispatch through a jump table. The jump table would be considered part of the instruction stream and included in the scope of the line table. This is not a case where you would see end_sequence; my mistake. The line table does not list every individual instruction. For compactness, it lists instructions only when the associated source location changes. All instructions between successive entries of the line table would have the same source location. Line 0 indicates one of two things....

There should be a line-table entry for the end of the function, which appears to be missing from the dump you provided. llvm-dwarfdump should report this address with 'end_sequence' in the Flags. Are you using a different dumper? I am not sure but my guess would be that inline data is not represented in the line table. The line table's primary purpose is to inform the debugger about good breakpoint locations, and clearly you do not want to set breakpoints in data....

...0 is_stmt 0x0000000000000040 25 0 1 0 0 is_stmt 0x0000000000000044 25 13 1 0 0 is_stmt prologue_end 0x0000000000000080 0 0 2 0 0 is_stmt 0x000000000000008b 0 0 2 0 0 is_stmt end_sequence the debug info is emitted by the DIBuilder like !3 = !DIFile(filename: "/folk/tmp/test/test.cpp", directory: "/folk/tmp/test") !45 = distinct !DISubprogram(linkageName: "_GLOBAL__sub_I_test.cpp", scope: !3, file: !3, type: !46, flags: DIFlagArtificial, spFlags: DISP...

...0 is_stmt 0x0000000000000040 25 0 1 0 0 is_stmt 0x0000000000000044 25 13 1 0 0 is_stmt prologue_end 0x0000000000000080 0 0 2 0 0 is_stmt 0x000000000000008b 0 0 2 0 0 is_stmt end_sequence the debug info is emitted by the DIBuilder like !3 = !DIFile(filename: "/folk/tmp/test/test.cpp", directory: "/folk/tmp/test") !45 = distinct !DISubprogram(linkageName: "_GLOBAL__sub_I_test.cpp", scope: !3, file: !3, type: !46, flags: DIFlagArtificial, spFlags: DISP...

Dear LLVM devs, I've noticed that LLVM's assembler (and hence clang) doesn't generate debug data when assembling, even when run with "-g". Users can add their own CFI/line number data with assembler directives. But GDB ignores the line number data if you don't have a DIE in the .debug_info section which identifies the compilation unit. (I'm not an expert on GDB, but

Hi paulr Thanks for your reply. Though DWARF info give me the code address ranges, there might be inline data. If so, how to handle this case? As for the dwarf line table. Sometimes, the source line might be zero. Do you know why? If all instructions should be describe in the line table, I think analyzing Dwarf line table is enough to get all the instructions addresses. Do you agree? I would

...logue_end > 0x0000000000000050 4 0 1 0 is_stmt > 0x0000000000000058 5 0 1 0 is_stmt > 0x000000000000005c 6 0 1 0 is_stmt > 0x0000000000000068 7 0 1 0 is_stmt > 0x0000000000000084 7 0 1 0 is_stmt end_sequence > > .debug_str contents: > 0x00000000: "clang version 3.3 (/opt/git.repo/clang.git/ > b422d20530588813b09057b45d5b383f0b175ced) (/opt/git.repo/llvm.git/ > 57b428f0a6be7b81bc364b0088992b1f820b516e)" > 0x00000099: "test.c" > 0x000000a0: "/home/yangyy/work...

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

Hi, all I ported llvm backend and lldb recently. Both tools can basically work. lldb is able to debug programs in asm style and frame unwinding is OK. But "frame variable XX" does not work because lldb is not able to determine the address of XX from debug info. Can someone give any clue? Thanks in advance. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML

Hello, I have my work on the nv vpe video decoder in a functional state. In case you didn't know this decoder accelerates mpeg2 video at the idct/mc level. I have verified that it works on nv40 hardware. I believe it works on nv30 hardware (and maybe some earlier hardware), but I cannot verify since I have none. I will reply with patches against the kernel, drm, ddx and mesa for

...t is worth a word. > The top fragment has the header, including the directory/file lists > because those are referenced by index. DW_LNE_define_file can't be > used. Each function has a fragment containing the sequence for that > function, starting with set_address and ending with end_sequence. > The bottom fragment is empty, existing only to allow the length to > be computed. Yep - can't remove dead file and directory names, unfortunately - and the line table's pretty compact, so not sure it'd be a great savings (especially compared to the ELF section overhead - at th...

On Wed, Jun 3, 2020 at 6:34 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > DWARF was designed in an era when COMDAT and ICF were not a thing, or at least not common, certainly not when talking about function code. The overhead of a unit occurred only once per translation unit, so that expense was reasonably amortized. > > > > Splitting functions into their own

...p fragment has the header, including the directory/file lists > > > because those are referenced by index. DW_LNE_define_file can't be > > > used. Each function has a fragment containing the sequence for that > > > function, starting with set_address and ending with end_sequence. > > > The bottom fragment is empty, existing only to allow the length to > > > be computed. > > > > Yep - can't remove dead file and directory names, unfortunately - and > > the line table's pretty compact, so not sure it'd be a great savings > &g...

...0000000000050 4 0 1 0 is_stmt > > 0x0000000000000058 5 0 1 0 is_stmt > > 0x000000000000005c 6 0 1 0 is_stmt > > 0x0000000000000068 7 0 1 0 is_stmt > > 0x0000000000000084 7 0 1 0 is_stmt end_sequence > > > > .debug_str contents: > > 0x00000000: "clang version 3.3 (/opt/git.repo/clang.git/ > b422d20530588813b09057b45d5b383f0b175ced) (/opt/git.repo/llvm.git/ > 57b428f0a6be7b81bc364b0088992b1f820b516e)" > > 0x00000099: "test.c" > > 0x000000a0...