Re: [lldb-dev] RFC: Simplifying SymbolFile interface
On 09/01/2019 20:59, Zachary Turner via lldb-dev wrote: The Native PDB symbol file plugin I think is mostly complete. It's at least almost as good as the old Windows-only PDB plugin in 90% of ways, while actually being significantly better in other ways (for example, there was a test that took over 2 minutes to run with the Windows-only PDB plugin, which now takes about 2 seconds to run with the native PDB plugin. While implementing this, I ran into several things that made my life quite difficult, and only later found out that I could have saved myself a lot of headache and time if the SymbolFile interface had been a little simpler and easier to understand. Specifically, I'd like to remove the heavy use of SymbolContext in the SymbolFile / SymbolVendor interface and replace it with more narrow and targeted parameter lists. Consider the case of someone calling FindTypes. In theory, today they can fill out any combination of Target, Module, Function, Block, CompileUnit, LineEntry, and Symbol. That's 2^7 different possible ways the function can be called. While obviously not all of these combinations make sense, the fact is that it greatly increases the API surface, which is bad for test coverage, bad for ease of understanding, bad for usability, and leads to a lot of dead code. For a person implementing this function for the first time, and who may not know all the details about how the rest of LLDB works, this is quite daunting because there's an inherent desire to implement the function faithfully "just in case", since they don't know all of the different ways the function might be called. This results in wasted time on the developer's part, because they end up implementing a bunch of functionality that is essentially dead code. We can certainly document for every single function "The implementor should be prepared to handle the case of fields X, Y, and Z being set, and handle it in such and such way", but I think it's easier to just change the interface to be more clear in the first place. Here are the cases I identified, and a proposal for how I could change the interface. 1) SymbolFile::ParseTypes(SymbolContext&) * In the entire codebase, this is only called with a CompileUnit set. We should change this to be ParseTypesForCompileUnit(CompileUnit&) so that the interface is self-documenting. A patch with this change is here [https://reviews.llvm.org/D56462] 2) SymbolFile::ParseDeclsForContext(CompilerDeclContext) * This is intended to only be used for parsing variables in a block. But should it be recursive? It's impossible to tell from the function name, so callers can't use it correctly and implementors can't implement it correctly. I spent 4 days trying to implement a generic version of this function for the NativePDB plugin only to find out that I only actually cared about block variables. I would propose changing this to ParseVariableDeclsForBlock(Block&). 3) These functions: * ParseCompileUnitLanguage(SymbolContext&) * ParseCompileUnitFunctions(SymbolContext&) * ParseCompileUnitLineTable(SymbolContext&) * ParseCompileUnitDebugMacros(SymbolContext&) * ParseCompileUnitSupportFiles(SymbolContext&) are only for CompileUnits (as the name implies. I propose changing the parameter from a SymbolContext& to a CompileUnit&. 4) SymbolFile::ParseFunctionBlocks(SymbolContext&) * This is intended to be used when the SymbolContexts m_function member is set. I propose changing this to SymbolFile::ParseFunctionBlocks(Function&). 5) SymbolFile::ParseVariablesForContext(CompilerDeclContext) * This function is only called with the the Context being a CompileUnit, Function, and Block. But does it need to be recursive? For a Function and Block it seems to be assumed to be recursive, and for a CompileUnit it seems to be assumed to not be recursive. For the former case, it's not actually clear how this function differs from ParseGlobalVariables, and for the latter case I would propose changing this to ParseImmedateVariablesForBlock(Block&). 6) SymbolFile::FindTypes(SymbolContext&). * This function is only called with the m_module field set, and since a SymbolFile is already tied to a module anyway, the parameter appears unnecessary. I propose changing this to SymbolFile::FindAllTypes() 7) SymbolFile::FindNamespace(SymbolContext&, ConstString, DeclContext*) is only called with default-constructed (i.e. null) SymbolContexts, making the first parameter unnecessary. I propose changing this to FindNamespace(ConstString, DeclContext*) 8) Module::FindTypes(SymbolContext &, ConstString, bool , size_t , DenseSet &, TypeList&): * After the change in #6, we can propagate this change upwards for greater benefit. The first parameter in Module::FindTypes(SymbolContext&, ...) now becomes unnecessary (and in fact, it was kind of unnecessary to begin with since in every case, the SymbolContext actually just had a
[lldb-dev] Figure our what global and static variables are accessed by what functions (at runtime)
Hi, I think that I can use the watchpoint command to set watchpoints on all global and static variables. Then run the lldb and parse the screen output to see what global and static variables are read/write-accessed by what functions. Is this a good strategy? Is there any other better ways to figure this kind of information out? -- Regards, Peng ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Figure our what global and static variables are accessed by what functions (at runtime)
On 10/01/2019 17:16, Peng Yu via lldb-dev wrote: Hi, I think that I can use the watchpoint command to set watchpoints on all global and static variables. Then run the lldb and parse the screen output to see what global and static variables are read/write-accessed by what functions. Is this a good strategy? Is there any other better ways to figure this kind of information out? Normally, a CPU only allows a very small (as in, ~4) watchpoints. So I think this strategy is bound to fail. If you really need dynamic information about this sort of thing (and not just the static "does the function reference this variable" kind), then I'd suggest trying to combine the static information (obtained either through analysis of the debug info, by looking at the relocations in the object files, or from the source code) with some dynamic instrumentation framework (the kinds used for coverage analysis) that can tell you whether a particular line of code (instruction) got executed. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Figure our what global and static variables are accessed by what functions (at runtime)
> Normally, a CPU only allows a very small (as in, ~4) watchpoints. So I > think this strategy is bound to fail. Thanks. I see there only 4 hardware watchpoints are supported on my machine. Is there a way to set software watchpoints? > If you really need dynamic information about this sort of thing (and not > just the static "does the function reference this variable" kind), then > I'd suggest trying to combine the static information (obtained either > through analysis of the debug info, by looking at the relocations in the > object files, or from the source code) Static information is also helpful here. Do you have specific information on what tools can help to provide such information? Thanks. > with some dynamic instrumentation > framework (the kinds used for coverage analysis) that can tell you > whether a particular line of code (instruction) got executed. Do you have specific tools to recommend? Thanks. -- Regards, Peng ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] RFC: Simplifying SymbolFile interface
On Thu, Jan 10, 2019 at 12:43 AM Pavel Labath via lldb-dev wrote: > > On 09/01/2019 20:59, Zachary Turner via lldb-dev wrote: > > The Native PDB symbol file plugin I think is mostly complete. It's at > > least almost as good as the old Windows-only PDB plugin in 90% of ways, > > while actually being significantly better in other ways (for example, > > there was a test that took over 2 minutes to run with the Windows-only > > PDB plugin, which now takes about 2 seconds to run with the native PDB > > plugin. > > > > While implementing this, I ran into several things that made my life > > quite difficult, and only later found out that I could have saved myself > > a lot of headache and time if the SymbolFile interface had been a little > > simpler and easier to understand. > > > > Specifically, I'd like to remove the heavy use of SymbolContext in the > > SymbolFile / SymbolVendor interface and replace it with more narrow and > > targeted parameter lists. > > > > Consider the case of someone calling FindTypes. In theory, today they > > can fill out any combination of Target, Module, Function, Block, > > CompileUnit, LineEntry, and Symbol. That's 2^7 different possible ways > > the function can be called. While obviously not all of these > > combinations make sense, the fact is that it greatly increases the API > > surface, which is bad for test coverage, bad for ease of understanding, > > bad for usability, and leads to a lot of dead code. > > > > For a person implementing this function for the first time, and who may > > not know all the details about how the rest of LLDB works, this is quite > > daunting because there's an inherent desire to implement the function > > faithfully "just in case", since they don't know all of the different > > ways the function might be called. > > > > This results in wasted time on the developer's part, because they end up > > implementing a bunch of functionality that is essentially dead code. > > > > We can certainly document for every single function "The implementor > > should be prepared to handle the case of fields X, Y, and Z being set, > > and handle it in such and such way", but I think it's easier to just > > change the interface to be more clear in the first place. > > > > > > Here are the cases I identified, and a proposal for how I could change > > the interface. > > > > 1) SymbolFile::ParseTypes(SymbolContext&) > >* In the entire codebase, this is only called with a CompileUnit > > set. We should change this to be ParseTypesForCompileUnit(CompileUnit&) > > so that the interface is self-documenting. A patch with this change is > > here [https://reviews.llvm.org/D56462] > > > > 2) SymbolFile::ParseDeclsForContext(CompilerDeclContext) > >* This is intended to only be used for parsing variables in a block. > > But should it be recursive? It's impossible to tell from the function > > name, so callers can't use it correctly and implementors can't implement > > it correctly. I spent 4 days trying to implement a generic version of > > this function for the NativePDB plugin only to find out that I only > > actually cared about block variables. I would propose changing this to > > ParseVariableDeclsForBlock(Block&). > > > > 3) These functions: > > * ParseCompileUnitLanguage(SymbolContext&) > > * ParseCompileUnitFunctions(SymbolContext&) > > * ParseCompileUnitLineTable(SymbolContext&) > > * ParseCompileUnitDebugMacros(SymbolContext&) > > * ParseCompileUnitSupportFiles(SymbolContext&) > > > > are only for CompileUnits (as the name implies. I propose changing the > > parameter from a SymbolContext& to a CompileUnit&. > > > > 4) SymbolFile::ParseFunctionBlocks(SymbolContext&) > > * This is intended to be used when the SymbolContexts m_function > > member is set. I propose changing this to > > SymbolFile::ParseFunctionBlocks(Function&). > > > > 5) SymbolFile::ParseVariablesForContext(CompilerDeclContext) > > * This function is only called with the the Context being a CompileUnit, > > Function, and Block. But does it need to be recursive? For a Function > > and Block it seems to be assumed to be recursive, and for a CompileUnit > > it seems to be assumed to not be recursive. For the former case, it's > > not actually clear how this function differs from ParseGlobalVariables, > > and for the latter case I would propose changing this to > > ParseImmedateVariablesForBlock(Block&). > > > > 6) SymbolFile::FindTypes(SymbolContext&). > > * This function is only called with the m_module field set, and since a > > SymbolFile is already tied to a module anyway, the parameter appears > > unnecessary. I propose changing this to SymbolFile::FindAllTypes() > > > > 7) SymbolFile::FindNamespace(SymbolContext&, ConstString, DeclContext*) > > is only called with default-constructed (i.e. null) SymbolContexts, > > making the first parameter unnecessary. I propose changing this to > > FindNamespace(ConstString, DeclContext*) > > > > > > 8) Module::FindTypes(Sy
[lldb-dev] LLVM git monorepo mirror published
The new official monorepo is published to LLVM's github organization, at: https://github.com/llvm/llvm-project. At this point, the repository should be considered stable -- there won't be any more rewrites which invalidate commit hashes (barring some _REALLY_ good reason...). The import process is currently being triggered via cron every minute on a redundant pair of llvm project AWS instances. You should currently expect the round-trip latency from an svn commit to it showing up in git to be somewhere around 20-90 seconds. (I'd like to reduce that latency, but it hasn't been the priority yet). The updated workflow docs, and instructions on migrating in-progress work have not yet been finalized, but will come soon. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 40287] New: lldb cannot debug an i386 elf (32 bit) executable on an amd64 platform, (FreeBSD 11.1 and 11.2)
https://bugs.llvm.org/show_bug.cgi?id=40287
Bug ID: 40287
Summary: lldb cannot debug an i386 elf (32 bit) executable on
an amd64 platform, (FreeBSD 11.1 and 11.2)
Product: lldb
Version: 6.0
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: john.haz...@fisglobal.com
CC: llvm-b...@lists.llvm.org
I posted this over a week ago on the BSD forums and while I had 50+ views, not
one reply.
This use to work on FreeBSD 11.0 which I believe was version 3.x.
I have distilled the problem down to the simplest example below. As a note, I
also tried it on the executable BSD utility uptime from a 32bit, i386, platform
snd it fails
prompt>uname -mKr
11.2-RELEASE amd64 1102000
prompt>
Code:
prompt>cat hello.cpp
#include
int main()
{
printf("Hello World\n");
}
prompt>
Building (CLANG with -m32 and verbose)
prompt>clang++ -m32 -v -static hello.cpp
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM
6.0.0)
Target: i386-unknown-freebsd11.2
Thread model: posix
InstalledDir: /usr/bin
"/usr/bin/clang++" -cc1 -triple i386-unknown-freebsd11.2 -emit-obj -mrelax-all
-disable-free -disable-llvm-verifier -discard-value-names -main-file-name
hello.cpp -static-define -mrelocation-model static -mthread-model posix
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486
-dwarf-column-info -debugger-tuning=gdb -v -resource-dir /usr/lib/clang/6.0.0
-internal-isystem /usr/include/c++/v1 -fdeprecated-macro
-fdebug-compilation-dir
/srctree/release_11_11_b0_test/ridsbase/batch_params/libbatch_params
-ferror-limit 19 -fmessage-length 80 -fobjc-runtime=gnustep -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/hello-669b69.o -x c++ hello.cpp
clang -cc1 version 6.0.0 based upon LLVM 6.0.0 default target
x86_64-unknown-freebsd11.2
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/v1
/usr/lib/clang/6.0.0/include
/usr/include
End of search list.
"/usr/bin/ld" --eh-frame-hdr -Bstatic -m elf_i386_fbsd -o a.out
/usr/lib32/crt1.o /usr/lib32/crti.o /usr/lib32/crtbeginT.o -L/usr/lib32
/tmp/hello-669b69.o -lc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/usr/lib32/crtend.o /usr/lib32/crtn.o
prompt>
Running the program checking the file type:
prompt>file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically
linked, for FreeBSD 11.2, FreeBSD-style, not stripped
prompt>./a.out
Hello World
prompt>
prompt>lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (i386).
(lldb) r
Process 25772 launching
Process 25772 launched: './a.out' (i386)
Process 25772 stopped
* thread #1, name = 'a.out', stop reason = signal SIGBUS: hardware error
frame #0: 0x
error: Bad address
(lldb)
It runs under gdb.
And of course lldb works beautifully on X86-64 elf format.
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
