search for: dw_op_fbreg

...rked as UNSUPPORTED. For example, the test/DebugInfo/2010-08-04-StackVariable.ll test could have the declarative part as ; REQUIRE: llc -mtriple=arm-apple-darwin    < /dev/null ; REQUIRE: llc -mtriple=x86_64-apple-darwin < /dev/null ; RUN: llc -O0 -mtriple=arm-apple-darwin    < %s | grep DW_OP_fbreg ; RUN: llc -O0 -mtriple=x86_64-apple-darwin < %s | grep DW_OP_fbreg ; Use DW_OP_fbreg in variable's location expression if the variable is in a stack slot. B.) $each_target placeholder, which could be used in the test run command to indicate that this is the type 2 test. This placeholder wi...

...ch is in this case Line No. 7. --------------------------------------------- 0x0000006d: DW_TAG_lexical_block DW_AT_low_pc (0x00000000002016d1) DW_AT_high_pc (0x000000000020170b) 0x0000007a: DW_TAG_variable DW_AT_location (DW_OP_fbreg -24) DW_AT_name ("Local") DW_AT_decl_file ("MainScope.c") DW_AT_decl_line (7) DW_AT_type (0x0000008a "int") ---------------------------------------------- The DWARF specificat...

...eref)”, and compiled with `-g -O0 -mllvm -fast-isel=false` (apparently FastISel doesn’t know what to do with frame-index dbg.values, but this is simple to fix). This seemed to work pretty well, and the DWARF looked legit: ``` 0x0000005f: DW_TAG_variable DW_AT_location (DW_OP_fbreg -20) DW_AT_name ("Local") 0x0000006d: DW_TAG_lexical_block DW_AT_low_pc (0x0000000100000f4f) DW_AT_high_pc (0x0000000100000f84) 0x0000007a: DW_TAG_variable DW_AT_location (0x00000000...

...>< 120> DW_TAG_variable DW_AT_name i DW_AT_decl_file 1 /home/yuri/test.c DW_AT_decl_line 4 DW_AT_type <144> DW_AT_location DW_OP_fbreg 0 <1>< 134> DW_TAG_base_type DW_AT_name int DW_AT_encoding DW_ATE_signed DW_AT_byte_size 4 <1>< 141> DW_TAG_base_type DW_AT_byte_size 4...

...>< 120> DW_TAG_variable DW_AT_name i DW_AT_decl_file 1 /home/yuri/test.c DW_AT_decl_line 4 DW_AT_type <144> DW_AT_location DW_OP_fbreg 0 <1>< 134> DW_TAG_base_type DW_AT_name int DW_AT_encoding DW_ATE_signed DW_AT_byte_size 4 <1>< 141> DW_TAG_base_type DW_AT_byte_size 4...

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

On Thu, Nov 14, 2019 at 1:27 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Nov 14, 2019, at 1:21 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > Hey folks, > > > > Would you all mind having a bit of a design discussion around the > feature both at the DWARF level and the LLVM implementation? It seems like > what's

> On Apr 1, 2020, at 2:56 AM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > > > Do you mean documenting the desired frontend behavior, or adding some verifier in > LLVM? A warning for the latter is that SROA may currently emit IR that contains a > mix of declares and values for different fragments of an aggregate variable, so I > assume that is something that

...information for 'c' parameter: ... <2><68>: Abbrev Number: 3 (DW_TAG_formal_parameter) <69> DW_AT_name : c <6b> DW_AT_start_scope : 0x3 <6f> DW_AT_type : <0x77> <73> DW_AT_location : 2 byte block: 91 8 (DW_OP_fbreg: 8) ... and value of 'c' can be inspected in GDB. So my questions are: Is there a way to enforce clang to generate DWARF information similar to pgcc ? For the x86 target, a C argument is passed by value on the stack. In the generated code, we can refer to the stack location of the argume...

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tim > Northover via llvm-dev > Sent: Wednesday, July 25, 2018 3:07 AM > To: Nat! > Cc: LLVM Developers Mailing List > Subject: Re: [llvm-dev] A question to the DWARF experts on symbol > indirection > > Hi Nat!, > > On Wed, 25 Jul 2018 at 01:21, Nat! via