search for: dw_at_prototyped

In llvm/lib/MC/MCDwarf.cpp's EmitGenDwarfAbbrev(), the DWARF abbreviation declaration for a DW_TAG_label includes a DW_AT_prototyped attribute, but the DWARF 4 specification indicates that the DW_AT_prototyped attribute is not a valid attribute for the DW_TAG_label debug information entry (DIE). In this case, EmitGenDwarfAbbrev() is clearly in violation of the DWARF 4 specification. However, I notice that one of the MachO lit t...

...> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Adrian Prantl via llvm-dev > Sent: Friday, January 18, 2019 5:20 PM > To: Snider, Todd > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Potential DWARF debug info bug: DW_TAG_label DIE > has a DW_AT_prototyped attribute > > > > > On Jan 18, 2019, at 1:06 PM, Snider, Todd via llvm-dev <llvm- > dev at lists.llvm.org> wrote: > > > > > > In llvm/lib/MC/MCDwarf.cpp’s EmitGenDwarfAbbrev(), the DWARF > abbreviation declaration for a DW_TAG_label includes a DW_AT_p...

...# DW_AT_comp_dir > .byte 2 # Abbrev [2] 0x22:0x5d DW_TAG_subprogram > .int Linfo_string3 # DW_AT_name > .byte 1 # DW_AT_decl_file > .byte 2 # DW_AT_decl_line > # DW_AT_prototyped > .int 127 # DW_AT_type > # DW_AT_external > .int Lfunc_begin0 # DW_AT_low_pc > .int Lfunc_end0 # DW_AT_high_pc > .byte 2 # DW_AT_frame_base > .byte 144 > .byte 60 >...

...# Abbrev [4] 0xba:0x24 DW_TAG_subprogram .long 222 # DW_AT_sibling .ascii "moo" # DW_AT_name .byte 0 .byte 1 # DW_AT_decl_file .byte 12 # DW_AT_decl_line .byte 1 # DW_AT_prototyped .byte 1 # DW_AT_external .long .Lfunc_begin0 # DW_AT_low_pc .long .Lfunc_end0 # DW_AT_high_pc .byte 1 # DW_AT_frame_base .byte 85 .byte 5 # Abbrev [5] 0xd1:0xc DW_TAG_formal_parameter .byte 120...

...0xc9 <b4> Unknown AT value: 3fe7: 1 <b4> DW_AT_frame_base : 1 byte block: 57 (DW_OP_reg7 (rsp)) <b6> DW_AT_name : (indirect string, offset: 0xaf): main <ba> DW_AT_decl_file : 1 <bb> DW_AT_decl_line : 16 <bc> DW_AT_prototyped : 1 <bc> DW_AT_type : <0x3f> <c0> DW_AT_external : 1 <c0> Unknown AT value: 3fe1: 1 <2><c0>: Abbrev Number: 8 (DW_TAG_formal_parameter) <c1> DW_AT_location : 0x23 (location list) <c5> DW_AT_name...

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

Hi I'm using llvm-5. Browsing the source of llvm-dwarfdump and trying it on some shared libraries, I see I can print the debug info (assuming it exists). For some function, I'm wondering if there's a short cut to prettyprinting the signature of a function in the library? I think, looking at the output, that enough information exists but it seems to involve looking at the subprogram

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

...e > base is defined in the parent DIE: > > 0x00000022: DW_TAG_subprogram [2] * > DW_AT_name( "main" ) > DW_AT_decl_file( "/home/yangyy/workspace/newlib/test.c" ) > DW_AT_decl_line( 2 ) > DW_AT_prototyped( true ) > DW_AT_type( {0x0000007f} ( int ) ) > DW_AT_external( true ) > DW_AT_low_pc( 0x00000028 ) > DW_AT_high_pc( 0x00000084 ) > DW_AT_frame_base( regx 0x0000003c ) > > So it says the frame b...

Hi, I am trying to execute a simple hello world program compiled like so: path/to/compiled/clang -o test --target=aarch64-linux-gnu -march=armv8.5-a -fsanitize=hwaddress --sysroot=/usr/aarch64-linux-gnu/ -L/usr/lib/gcc/aarch64-linux-gnu/10.1.0/ -g test.c However, when I look at the disassembly, there is an unknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1