[lldb-dev] Extern globals showing up as locals
I'm seeing particular globals spuriously being reported as local variables:
they're returned by SBFrame::GetVariables(true, true, false, true) because
their scope is eValueTypeVariableLocal.
I've tracked down the problem but don't know DWARF well enough to determine
the right fix. Anyone want to help me out?
--
I can reproduce with the following program:
struct Obj{};
namespace N { extern Obj& o; }
using N::o;
int main(){}
When building with clang -g, lldb gives
(lldb) frame v -g -s
LOCAL: (Obj &) N::o =
(lldb) target v -s
LOCAL: (Obj &) N::o =
It seems confused about whether it's local or global.
readelf --dump-debug has the following info for the variable:
<2><31>: Abbrev Number: 3 (DW_TAG_variable)
<32> DW_AT_name: (indirect string, offset: 0x51): o
<36> DW_AT_type: <0x42>
<3a> DW_AT_external: 1
<3a> DW_AT_decl_file : 1
<3b> DW_AT_decl_line : 2
<3c> DW_AT_declaration : 1
<3c> DW_AT_location: 0 byte block:()
<3d> DW_AT_linkage_name: (indirect string, offset: 0x57): _ZN1N1oE
It seems that the zero-length location is a problem: SymbolFileDWARF.cpp
thinks a variable without a valid location must be static or local.
FWIW, gdb on the clang-built binary shows N::o as an optimized-out global,
which seems fine. gcc generates debug info that omits the DW_AT_location,
which causes gdb to hide it completely I think.
Cheers, Sam
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Extern globals showing up as locals
I sent my best attempt in https://reviews.llvm.org/D26908, would appreciate
any advice there :-)
On Fri, Nov 18, 2016 at 7:22 PM, Sam McCall wrote:
> I'm seeing particular globals spuriously being reported as local
> variables: they're returned by SBFrame::GetVariables(true, true, false,
> true) because their scope is eValueTypeVariableLocal.
>
> I've tracked down the problem but don't know DWARF well enough to
> determine the right fix. Anyone want to help me out?
>
> --
>
> I can reproduce with the following program:
>
> struct Obj{};
> namespace N { extern Obj& o; }
> using N::o;
> int main(){}
>
>
> When building with clang -g, lldb gives
>
> (lldb) frame v -g -s
>
> LOCAL: (Obj &) N::o =
>
> (lldb) target v -s
>
> LOCAL: (Obj &) N::o =
>
> It seems confused about whether it's local or global.
>
> readelf --dump-debug has the following info for the variable:
> <2><31>: Abbrev Number: 3 (DW_TAG_variable)
> <32> DW_AT_name: (indirect string, offset: 0x51): o
> <36> DW_AT_type: <0x42>
> <3a> DW_AT_external: 1
> <3a> DW_AT_decl_file : 1
> <3b> DW_AT_decl_line : 2
> <3c> DW_AT_declaration : 1
> <3c> DW_AT_location: 0 byte block:()
> <3d> DW_AT_linkage_name: (indirect string, offset: 0x57): _ZN1N1oE
> It seems that the zero-length location is a problem: SymbolFileDWARF.cpp
> thinks a variable without a valid location must be static or local.
>
> FWIW, gdb on the clang-built binary shows N::o as an optimized-out global,
> which seems fine. gcc generates debug info that omits the DW_AT_location,
> which causes gdb to hide it completely I think.
>
> Cheers, Sam
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Classes inheriting from RegisterContextDarwin_arm, and __APPLE__
The implementation of RegisterContextDarwin_arm is surrounded by #if defined(__APPLE__). Some other files define subclasses, e.g. RegisterContextDarwin_arm_Mach in ObjectFileMachO.cpp, that are built on non-apple machines. This seems... confusing, and causes me some problems trying to do dynamic linking. Is there something wrong here, or should I just avoid doing that :-) Cheers, Sam ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] "devirtualizing" files in the VFS
I'd like to get some more perspectives on the role of the VirtualFileSystem abstraction in llvm/Support. (The VFS layer has recently moved from Clang to LLVM, so crossposting to both lists) https://reviews.llvm.org/D54277 proposed adding a function to VirtualFileSystem to get the underlying "real file" path from a VFS path. LLDB is starting to use VFS for some filesystem interactions, but wants/needs to keep using native IO (FILE*, file descriptors) for others. There's some more context/discussion in the review. My perspective is coloured by work on clang tooling, clangd etc. There we rely on VFS to ensure code (typically clang library code) works in a variety of environments, e.g: in an IDE the edited file is consistently used rather than the one on disk clang-tidy checks work on a local codebase, but our code review tool also runs them as a service This works because all IO goes through the VFS, so VFSes are substitutable. We tend to rely on the static type system to ensure this (most people write lit tests that use the real FS). Adding facilities to use native IO together with VFS works against this, e.g. a likely interface is // Returns the OS-native path to the specified virtual file. // Returns None if Path doesn't describe a native file, or its path is unknown. Optional FileSystem::getNativePath(string Path) Most potential uses of such a function are going to produce code that doesn't work well with arbitrary VFSes. Anecdotally, filesystems are confusing, and most features exposed by VFS end up getting misused if possible. So those are my reasons for pushing back on this change, but I'm not sure how strong they are. I think broadly the alternatives for LLDB are: make a change like this to the VFS APIs migrate to actually doing IO using VFS (likely a lot of work) know which concrete VFSes they construct, and track the needed info externally stop using VFS, and build separate abstractions for tracking remapping of native files etc abandon the new features that depend on this file remapping As a purist, 2 and 4 seem like the cleanest options, but that's easy to say when it's someone else's work. What path should we take here? Cheers, Sam ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] "devirtualizing" files in the VFS
On Tue, Nov 27, 2018 at 7:01 PM Jonas Devlieghere wrote: > Hi Sam, > > Does extending the status with a path sound reasonable? This would work > similar to the current Name field, which is controlled by UseExternalName. > > Please let me know what you think. > > Thanks, > Jonas > Design-wise, adding a second Name field to Status doesn't seem significantly different than adding a "getOtherName" field to VFS. I don't think it's really reasonable to have this in the VFS interfaces, because using it in any way means you're coupled to particular implementations. Implementation-wise, it seems the only way to do that would be to add an extra string to Status, and some applications probably keep a lot of Status objects. So it doesn't seem like an improvement vs the VFS method. Overall I think if LLDB wants to wants to break abstraction and use the native filesystem sometimes, it should have concrete private implementations with wider interfaces, and bridge to common code by having them implement the VFS interfaces. The contract of VFS may have been "real filesystem with some redirected files", but I don't think it has been for several years, and people rely on this. I'm not an owner here though. I don't really know how these decisions get made, and would like to hear more opinions. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
