[lldb-dev] target and host with different endianness
We have a big-endian target that we debug from LLDB running on Windows through a custom process plugin and communication protocol. The target's default byte order is set to eByteOrderBig in 'g_core_definitions' in ArchSpec.cpp. Most features work correctly (registers, variables, breakpoints, disassembly), but expressions seem to ignore arch endianness: For example: (lldb) reg read pc pc = 0x00400020 arithmetic.elf`main + 32 at main.c:12 (lldb) expr -f hex -- $pc (unsigned int) $2 = 0x20004000 (lldb) Has this scenario (big-endian target and little-endian host) been tested/used ? Thanks, -Philippe ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Prefered way to identify target device in tests?
I'm working on getting the tests running with Hexagon, and have a question
about identifying the target architecture.
Hexagon LLVM doesn't use a couple architectures like "x86_64" or "i386",
instead we have many architectures, like "v4", "v5", "v55", "v56", v60", so
using self.getArchitecture() can be problematic. I've got a list of Hexagon
architectures in a global supported_hexagon_versions in lldbtest.py. When I
need to check for Hexagon, should I do something like "self.getArchitecture
in supported_hexagon_versions", or something like this:
self.runCmd("target list")
if "arch=hexagon-*-*," in self.res.GetOutput():
?
Ted
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 26583] New: lldb lacks an equivalent to gdb's "directory" command
https://llvm.org/bugs/show_bug.cgi?id=26583 Bug ID: 26583 Summary: lldb lacks an equivalent to gdb's "directory" command Product: lldb Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ema...@freebsd.org CC: llvm-b...@lists.llvm.org Classification: Unclassified A FreeBSD user wondered how to achieve the same effect as GDB's "directory" command in LLDB, and it looks like we don't have an equivalent yet. Unlike target.source-map which allows a path mapping (useful if e.g. the entire source tree is available in a different location) the directory command just controls a list of directories to search by source file base name. -- 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
[lldb-dev] Making a new symbol provider
Hi, I want to make a new symbol provider to teach LLDB to understand microsoft PDB files. I've been looking over the various symbol APIs, and I have a few questions. 1. Under what circumstances do I need a custom SymbolVendor? The way pdb works is that generally there is 1 file that contains all the debug info needed for a single binary (so or executable). Given a list of paths, we can then determine if there is a matching PDB in one of those paths. Is it better to do this in the CalculateAbilities() function of the symbol file plugin (by just returning 0 if we don't find a match) or do we need to do something more complicated? 2. Why is there a function called ParseCompileUnitLanguage? The CompileUnit class already stores the language when ParseCompileUnit is called, and ParseCompileUnitLanguage is implemented by just getting that value out. What is the poitn of this function? 3. There's a function called ParseCompileUnitDebugMacros. Is this referring to C / C++ macros? Like #define FOO 7? What is that used for? I don't believe info about preprocessor definitions are stored in PDB. Is this going to cause problems? 4. ParseCompileUnitSupportFiles. What are "support files"? Given a file "foo.cpp" is this supposed to be header files etc? 5. ParseCompileUnitLineTable. On the LineTable class you can add "line sequences" or individual entries. What's the difference here? Is there any disadvantage to adding every single line entry in the line table using the InsertLineEntry instead of building a line sequence and inserting the sequence? I will probably have some more questions as I continue down this path. For now I'm planning to implement the minimum amount of functionality required just to make LLDB locate and open a PDB for an executable without actually returning anything useful from it. So when I start filling out types, functions, etc I may have some more questions. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Making a new symbol provider
> On Feb 11, 2016, at 3:41 PM, Zachary Turner via lldb-dev
> wrote:
>
> Hi,
>
> I want to make a new symbol provider to teach LLDB to understand microsoft
> PDB files. I've been looking over the various symbol APIs, and I have a few
> questions.
>
> 1. Under what circumstances do I need a custom SymbolVendor? The way pdb
> works is that generally there is 1 file that contains all the debug info
> needed for a single binary (so or executable). Given a list of paths, we can
> then determine if there is a matching PDB in one of those paths. Is it
> better to do this in the CalculateAbilities() function of the symbol file
> plugin (by just returning 0 if we don't find a match) or do we need to do
> something more complicated?
I would suggest make a SymbolVendorPDB that only enables itself if you are able
to find the PDB files for your COFF file. So look at your COFF file, and I
presume somewhere in there there is a pointer to one or more PDB files inside
that file? CalculateAbililties is the correct place to see if a COFF file has
pointers to PDB files and making sure those files exist before you say that you
can provide any abilities.
>
> 2. Why is there a function called ParseCompileUnitLanguage? The CompileUnit
> class already stores the language when ParseCompileUnit is called, and
> ParseCompileUnitLanguage is implemented by just getting that value out. What
> is the poitn of this function?
If we are constructing CompileUnit instances with a valid language, we will
never need to call the ParseCompileUnitLanguage function on
SymbolVendor/SymbolFile, but it it is eLanguageTypeInvalid, we will lazily
populate this later.
>
> 3. There's a function called ParseCompileUnitDebugMacros. Is this referring
> to C / C++ macros? Like #define FOO 7? What is that used for? I don't
> believe info about preprocessor definitions are stored in PDB. Is this going
> to cause problems?
Nope, just don't implement. Hopefully there is a default implementation that
does nothing. We should imply that by having a default implementation for this
that there is nothing wrong with not filling it in.
>
> 4. ParseCompileUnitSupportFiles. What are "support files"? Given a file
> "foo.cpp" is this supposed to be header files etc?
This is largely mirroring how DWARF structures its data, but in general a
compile unit might have files that it uses for line tables and decl file for
things like variables.
So any files in your line table should be in here. In DWARF the line tables use
file indexes in their line tables to save space. Also any DWARF info that says
"I am declared on line 12 of file 'Foo.c'" will use an index to refer to
'Foo.c'. We use the compile unit support files for this:
case DW_AT_decl_file:
decl.SetFile(sc.comp_unit->GetSupportFiles().GetFileSpecAtIndex(file_idx));
break;
The macro support you mention above also uses file indexes when referring to
files.
So the support files should be a list of files that make sense to your PDB
parser in case your PDB uses file indexes when referring to files. Since LLDB
uses a partial parsing style of debug info, we only expand debug info into
agnostic LLDB info lazily as the information is needed. All symbol files also
get to pick their own identifiers for everything. For DWARF, we use the DIE
offset as the identifier. So say you parse DWARF that looks like:
0x000b: TAG_compile_unit [1] *
AT_producer( "Apple LLVM version 7.0.0 (clang-700.1.72)" )
AT_language( DW_LANG_C99 )
AT_name( "main.c" )
AT_stmt_list( 0x )
AT_comp_dir( "/Volumes/work/gclayton/Documents/src/args" )
AT_low_pc( 0x00010cf0 )
AT_high_pc( 0x00010e9b )
0x002e: TAG_subprogram [2] *
AT_low_pc( 0x00010cf0 )
AT_high_pc( 0x00010e9b )
AT_frame_base( rbp )
AT_name( "main" )
AT_decl_file( "main.c" )
AT_decl_line( 9 )
AT_prototyped( 0x01 )
AT_type( {0x00c6} ( int ) )
AT_external( 0x01 )
0x004d: TAG_formal_parameter [3]
AT_location( fbreg -1048 )
AT_name( "argc" )
AT_decl_file( "main.c" )
AT_decl_line( 9 )
AT_type( {0x00c6} ( int ) )
0x005c: TAG_formal_parameter [3]
AT_location( fbreg -1056 )
AT_name( "argv" )
AT_decl_file( "main.c" )
AT_decl_line( 9 )
AT_type( {0x00cd} ( const char** ) )
The ID of the compile unit is 0x000b since that is the DIE offset for the
compile unit. If we ask the compile unit any questions through the
lldb_private::CompileUnit, we can always extract the ID from the co
Re: [lldb-dev] target and host with different endianness
> On Feb 11, 2016, at 7:55 AM, Philippe Lavoie via lldb-dev > wrote: > > > We have a big-endian target that we debug from LLDB running on Windows > through a custom process plugin and communication protocol. > > The target's default byte order is set to eByteOrderBig in > 'g_core_definitions' in ArchSpec.cpp. > > Most features work correctly (registers, variables, breakpoints, > disassembly), but expressions seem to ignore arch endianness: > > For example: > > (lldb) reg read pc > pc = 0x00400020 arithmetic.elf`main + 32 at main.c:12 > (lldb) expr -f hex -- $pc > (unsigned int) $2 = 0x20004000 > (lldb) > > Has this scenario (big-endian target and little-endian host) been tested/used > ? Most things are currently little endian, so you will probably be one of the first. There shouldn't be much that needs to be fixed. All data we extract from memory is done via DataExtractor objects and they do have the notion of big and little endian, so there shouldn't be much more work than making sure the byte order gets correctly placed into the appropriate DataExtractor objects so that values are extracted correctly. I would guess the lldb_private::ValueObject's m_data member doesn't have the right byte order. The ValueObject should have a execution context (target, process, thread, frame, any of which should be valid) and the byte order can be retrieved from the Target's ArchSpec. Let me know if you need any help, Greg Clayton ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Making a new symbol provider
On Thu, Feb 11, 2016 at 5:35 PM Greg Clayton wrote: > > > On Feb 11, 2016, at 3:41 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hi, > > > > I want to make a new symbol provider to teach LLDB to understand > microsoft PDB files. I've been looking over the various symbol APIs, and I > have a few questions. > > > > 1. Under what circumstances do I need a custom SymbolVendor? The way > pdb works is that generally there is 1 file that contains all the debug > info needed for a single binary (so or executable). Given a list of paths, > we can then determine if there is a matching PDB in one of those paths. Is > it better to do this in the CalculateAbilities() function of the symbol > file plugin (by just returning 0 if we don't find a match) or do we need to > do something more complicated? > > I would suggest make a SymbolVendorPDB that only enables itself if you are > able to find the PDB files for your COFF file. So look at your COFF file, > and I presume somewhere in there there is a pointer to one or more PDB > files inside that file? CalculateAbililties is the correct place to see if > a COFF file has pointers to PDB files and making sure those files exist > before you say that you can provide any abilities. > Currently we use the operating system to query the PDBs. This could change in the future, but for now that's how we're doing it. The operating system does all the work of finding, matching, and loading the PDB for us, and it does it all in one call. So if we put this in the symbol vendor, there's no way to say "is there a PDB" without also saying "actually load all the data from the PDB" at the same time. So I'm not sure if there's a solution to this in there, because obviously I dont' want to load it twice. One question I had about SymbolVendor, is that I looked at SymbolVendorELF.cpp and it seems to boil down to this notion of "symbol file representations". All the logic in SymbolVendorELF exists just to add some object file representations. What is this supposed to represent? I've got an exe or something, what other "representation" is there other than the exe itself? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 26592] New: [LLDB][MIPS] TestInferiorAssert tests fail if section .gnu_debuglink is not available in libc.so.6
https://llvm.org/bugs/show_bug.cgi?id=26592 Bug ID: 26592 Summary: [LLDB][MIPS] TestInferiorAssert tests fail if section .gnu_debuglink is not available in libc.so.6 Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: nitesh.j...@imgtec.com CC: llvm-b...@lists.llvm.org Classification: Unclassified The loaded library (like libc.so) may not have its debug version available on the system (section .gnu_debuglink is not available). The debug version contains additional symbol information (such as __assert_perror_fail). Backtrace/function bound fails when symbol information is missing. -- 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
