similar to: [LLVMdev] DBG_VALUE instruction format and generation

Hi Adrian, > quite a lot of work Large amounts of credit should go to llvm-reduce, which was fundamental to getting any of this done, > I've skimmed your implementation and it looks nice and well-documented. The thing that worries me is the over-complicated lattices -- I didn't anticipate the problem, and there's a risk that it's more complex than it needs to be. As it

> I don't see how this is a meaningful distinction in LLVM IR. In LLVM IR we only have SSA values. An SSA value could be an alloca, or a gep into an alloca, or spilled onto the stack at the MIR level, in which case the dbg.value should get lowered into a memory location (if it isn't explicitly a DW_OP_stack_value). I think the distinction is still important; even at the IR level, if we

> We have plans to actually compile the symbolizer into the binary and do > in-process symbolization, but it's not there yet. nice! > I'm confused here. compiler-rt and clang/llvm instrumentation depend on each other These two projects don't need to be interdependent and, for the most part, they aren't. In the same way that llvm does not depend on clang, compiler-rt

> I'm not sure this will work as stated here. Indirectness is (mostly) orthogonal to DW_OP_stack_value. DW_OP_stack_value denotes that we reconstructed the value of the variable, but it doesn't exist in the program ("The DW_OP_stack_value operation specifies that the object does not exist in memory but its value is nonetheless known"), for example, a constant value. I think we

> That makes sense, and I think for "direct" values in your definition it is true that all direct values are r-values. > Why do we need DW_OP_LLVM_direct when we already have DW_OP_LLVM_stack_value? Can you give an example of something that is definitely not a stack value, but direct? The difference in definition is the intention: DW_OP_LLVM_direct means "we'd like this

It's probably best to open a bug. -Andy From: Alexey Samsonov [mailto:samsonov at google.com] Sent: Thursday, January 31, 2013 12:27 AM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: Re: Assertions in RuntimeDyldELF in ExecutionEngine/MCJIT tests On Wed, Jan 30, 2013 at 8:34 PM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote:

Hi all, An early implementation of extending debug ranges and providing multiple location support is done here: http://reviews.llvm.org/D11933 Design document: https://docs.google.com/document/d/1noDVWTvTWBdYdweICPBwvwyt8QvX4KHl7j3XKNSg1nE/edit?usp=sharing On Jun 24, 2015, at 12:12 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: Hi Adrian, You might want to take a look at abandoned

Yes, at some point we definitely should introduce stubs as a last resort for x86-64 relocations when the sections are too far apart, but I'd like to avoid it whenever possible. What I meant in my previous message was that I'd have RecordingMemoryManager use something other than malloc (such as the memory API used by SectionMemoryManager) to keep section near one another. -Andy From:

On Thu, May 30, 2013 at 3:40 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > Cool, can you use clang 3.3 then? :) > > I can, but digging deeper I see that the compiler-rt sanitizer tests > depend on just-built-clang for its object instrumentation. The next time > the instrumentation changes, I'd expect those tests to break. If the lit > tests that require

Currently there is a series of patches undergoing review[0] that seek to enable the use of multiple IR/MIR values when describing a source variable's location. The current plan for the MIR is to add a new instruction, DBG_VALUE_LIST, that supports this functionality by having a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely

> Yeah, because that decision can only be made much later in LLVM in AsmPrinter/DwarfExpression.cpp. > In DWARF, DW_OP_reg(x) is a register l-value, all others can either be l-values or r-values depending on whether there is a DW_OP_stack_value/DW_OP_implicit* at the end. Yes, it might not be clear but that's what I'm trying to say. Out of the non-empty DWARF locations, register and

On Mar 7, 2012, at 5:19 PM, Pranav Bhandarkar <pranavb at codeaurora.org> wrote: > Hi, > > I have a case that is causing me grief in the form of an assert. The prolog > Epilog inserter tries to remove Frame Index references. I have a DBG_VALUE > instruction that looks like this (alongwith the Frame Index). This is for > the Hexagon backend. > **************************

I have a question regarding the DBG_VALUE instruction. IIUC the DBG_VALUE appears in two different forms: 1. DBG_VALUE( %Reg, %Reg, metadata) 2. DBG_VALUE(%Reg, offset, metadata) In the first version, the second operand is always a %noreg in the form of: DBG_VALUE(%Reg, %noreg, metadata). Is it possible to have a different version of DBG_VALUE that only has 2 operands which will have only

On Wed, Jan 30, 2013 at 8:34 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Yes, at some point we definitely should introduce stubs as a last resort > for x86-64 relocations when the sections are too far apart, but I’d like to > avoid it whenever possible.**** > > ** ** > > What I meant in my previous message was that I’d have > RecordingMemoryManager use

Fix is in (r167460). On Tue, Nov 6, 2012 at 6:18 PM, Kostya Serebryany <kcc at google.com> wrote: > The fix is under review. > > --kcc > > > On Tue, Nov 6, 2012 at 6:08 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > >> At 167457 on x86_64-apple-darwin12, I am seeing a slew of >> AddressSanitizer failures due to >> unresolved symbols

Hi Alexey, I think the most likely way to resolve this is to have the RecordingMemoryManager do something more complex to manage its allocations in such a way as to guarantee that they are all within proximity of one another. The code that is asserting is handling a relocation where code was generated to use a 32-bit relative offset in 64-bit code. If the two sections involved really are more

On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: > I'm investigating a bug associated with debug information that manifests > itself in the XCore backend (PR11105). I'd like to understand what the > expected behavior of eliminateFrameIndex() is when it is called on a > dbg_value machine instruction. That is up to the target. The TII::emitFrameIndexDebugValue() hook is

On 10/10/11 19:19, Jakob Stoklund Olesen wrote: > On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: >> I'm investigating a bug associated with debug information that manifests >> itself in the XCore backend (PR11105). I'd like to understand what the >> expected behavior of eliminateFrameIndex() is when it is called on a >> dbg_value machine instruction. >

Hi, I have a case that is causing me grief in the form of an assert. The prolog Epilog inserter tries to remove Frame Index references. I have a DBG_VALUE instruction that looks like this (alongwith the Frame Index). This is for the Hexagon backend. ************************** fi#2: size=4, align=4, at location [SP-84] DBG_VALUE <fi#2>, 0, !"fooBar"; line no:299

Hi Andrew, Looks like RecordingMemoryManager in lli just calls malloc() and it would be strange to make assumptions (or enforce) that the difference between two returned pointers in 64-bit virtual address space will be fit into 32 bits. Can we do smth similar to what Adhemerval proposed (see the special case in processRelocationRef for ELF::R_PPC64_REL24 relocations)? On Tue, Jan 29, 2013 at