Re: [Dwarf-Discuss] Stack tracing and return addresses off by 1
To add to what Greg described you may also want to look at section 6.4.4 of the DWARF 5 specification that discusses these issues. In particular note the non-normative description in the fourth paragraph. > 6.4.4 Call Frame Calling Address > > *When virtually unwinding frames, consumers frequently wish to obtain the > address of the instruction which called a subroutine. This information is not > always provided. Typically, however, one of the registers in the virtual > unwind table is the Return Address.* > > If a Return Address register is defined in the virtual unwind table, and its > rule is undefined (for example, by DW_CFA_undefined), then there is no > return address and no call address, and the virtual unwind of stack > activations is complete. > > *In most cases the return address is in the same context as the calling > address, but that need not be the case, especially if the producer knows in > some way the call never will return. The context of the ’return address’ > might be on a different line, in a different lexical block, or past the end > of the calling subroutine. If a consumer were to assume that it was in the > same context as the calling address, the virtual unwind might fail.* > > *For architectures with constant-length instructions where the return address > immediately follows the call instruction, a simple solution is to subtract > the length of an instruction from the return address to obtain the calling > instruction. For architectures with variable-length instructions (for > example, x86), this is not possible. However, subtracting 1 from the return > address, although not guaranteed to provide the exact calling address, > generally will produce an address within the same context as the calling > address, and that usually is sufficient.* Thanks, -Tony Tye ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] modeling different address spaces
A compiler may promote part of a variable to a scratch pad memory address space. Thanks, -Tony Tye -Original Message- From: Michael Eager On 7/30/20 5:17 PM, Tye, Tony via Dwarf-Discuss wrote: > For optimized code involving multiple address spaces it is possible to > run into cases where the location of a source language variable > requires multiple address spaces. For example, a source variable may > be optimized and different pieces may be in different places including > memory of multiple address spaces, registers, etc. Can you explain this more? DWARF handles the situation where part of a variable is in memory and part in a register or in multiple registers. When would you have a variable which was in multiple address spaces? -- Michael Eager ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] modeling different address spaces
For optimized code involving multiple address spaces it is possible to run into cases where the location of a source language variable requires multiple address spaces. For example, a source variable may be optimized and different pieces may be in different places including memory of multiple address spaces, registers, etc. Describing this situation with a DW_AT_address_class on a source language variable is not possible as it provides a single address space that applies to the variable as a whole. The concept of "address space" is not available on the expression stack where a composite location description is created. Instead, making address space a property of memory location descriptions and making location descriptions a first-class concept on the expression stack solves the problem in a general way and leads to other nice properties. Thanks, -Tony ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
[Dwarf-Discuss] How to represent address space information in DWARF
Another question that has been raised as part of the HSA Foundation (http://www.hsafoundation.com/) tools working group relates to the manner that address spaces should be represented in DWARF. HSA defines segments in which variables can be allocated. These are basically the same as the address spaces of OpenCL. HSA defines kernels that are basically the same as OpenCL kernels. A kernel is a grid launch of separate threads of execution (termed work-items). These work-items are grouped into work-groups. The work-items can access one of three main memory segments: 1. The global segment is accessible by all work-items. In hardware it is typically just the global memory. 2. The group segment (corresponding to the local address space of OpenCL) is accessible only to the work-items in the same work-group. Each work-group has its own copy of variables allocated in the group segment. On GPU hardware this can be implemented as special hardware managed scratch pad memory (not part of globally addressable memory), with special hardware instructions to access it. 3. The private segment is accessible to a single work-item. Each work-item has its own copy of variables allocated in the private segment. On GPU hardware this could also involve special hardware instructions. HSA also defines the concept of a flat address (similar to OpenCL generic addresses). It is essentially a linearization of the addresses of the 3 address spaces. For example, one range of a flat address maps to the group segment, another range maps to the private segment, and the rest map directly to the global segment. However, it is target specific what exact method is used to achieve the linearization. The following was the conclusion we reached from reading the DWARF standard and looking at how gdb and lldb would use the information. We are currently working on creating a patch for LLVM to support address spaces and would appreciate any feedback on if this matches the intended usage of DWARF features to support this style of address space. 1. Use the DW_AT_address_class to specify that the value of a pointer-like value is the address within a specific address space. Pointer-like values include pointers, references, functions and function types. For HSA we are really only concerned with pointer/reference values currently. It would apply to a pointer-like type DIE, or a variable with a pointer-like type. In the case of a variable it does not specify the address space of the variable's location, but specifies how to treat the address value stored in the variable. 2. Use DW_OP_xderef in the location expression of a variable to specify the address space in which the variable is located. Since location expressions can specify different locations depending on the PC, this allows the variable to be optimized to have multiple locations. For example, sometimes in a memory location in the group address space, sometimes in a register, sometimes in a memory location in the private address space (maybe due to spilling of the register), etc. Attempting to use DW_AT_address_class on variables to specify their address space location conflicts with DWARF stating that it applies to the pointee as described in #1. It also breaks the flexibility of location expressions allowing the location to change according to PC. When a debugger evaluates a DWARF location expression it can generate a flat address to encode the address space. It can do this by implementing the XDEREF as a target specific conversion from a segment address into a flat address. Similarly when using a value as an address that has a pointer-like type with an address class, the value can be converted to a flat address. When accessing addresses the debugger would have to provide the "current thread" so that the correct group/private address space instance can be accessed when given a flat address that maps to the group or private segments. It appears both gdb and lldb provide this. Thanks, Tony Tye ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
