[lldb-dev] [Bug 49678] New: SymbolFile/DWARF/dwarf5-debug_line-file-index.s crash lldb on arm linux
https://bugs.llvm.org/show_bug.cgi?id=49678 Bug ID: 49678 Summary: SymbolFile/DWARF/dwarf5-debug_line-file-index.s crash lldb on arm linux Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: omair.jav...@linaro.org CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org /home/omair.javaid/work/lldb/build/armhf/bin/lldb --no-lldbinit -S /home/omair.javaid/work/lldb/build/armhf/tools/lldb/test/Shell/lit-lldb-init /home/omair.javaid/work/lldb/build/armhf/tools/lldb/test/SymbolFile/DWARF/Output/dwarf5-debug_line-file-index.s.tmp -o "image lookup -f hello.c -l 1" (lldb) command source -s 0 '/home/omair.javaid/work/lldb/build/armhf/tools/lldb/test/Shell/lit-lldb-init' Executing commands in '/home/omair.javaid/work/lldb/build/armhf/tools/lldb/test/Shell/lit-lldb-init'. (lldb) # LLDB init file for the LIT tests. (lldb) settings set symbols.enable-external-lookup false (lldb) settings set plugin.process.gdb-remote.packet-timeout 60 (lldb) settings set interpreter.echo-comment-commands false (lldb) settings set symbols.clang-modules-cache-path "/home/omair.javaid/work/lldb/build/armhf/lldb-test-build.noindex/module-cache-lldb" (lldb) settings set target.auto-apply-fixits false (lldb) settings set target.inherit-tcc true (lldb) settings set target.detach-on-error false (lldb) target create "/home/omair.javaid/work/lldb/build/armhf/tools/lldb/test/SymbolFile/DWARF/Output/dwarf5-debug_line-file-index.s.tmp" Current executable set to '/home/omair.javaid/work/lldb/build/armhf/tools/lldb/test/SymbolFile/DWARF/Output/dwarf5-debug_line-file-index.s.tmp' (x86_64). (lldb) image lookup -f hello.c -l 1 PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/omair.javaid/work/lldb/build/armhf/bin/lldb --no-lldbinit -S /home/omair.javaid/work/lldb/build/armhf/tools/lldb/test/Shell/lit-lldb-init /home/omair.javaid/work/lldb/build/armhf/tools/lldb/test/SymbolFile/DWARF/Output/dwarf5-debug_line-file-index.s.tmp -o "image lookup -f hello.c -l 1" Segmentation fault (core dumped) -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 49678] SymbolFile/DWARF/dwarf5-debug_line-file-index.s crash lldb on arm linux
https://bugs.llvm.org/show_bug.cgi?id=49678 lab...@google.com changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |lab...@google.com CC||lab...@google.com --- Comment #2 from lab...@google.com --- I believe 10d54e2f8d will fix this. Or, more like, work around the problem, since the invalid input should not cause a crash. Lets not close this bug until we understand what's happening there... -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb versus visual studio
> On Mar 20, 2021, at 8:57 AM, Franz Fehringer via lldb-dev > wrote: > > Dear lldb-dev community, > > First a disclaimer: If my question is inappropriate for this (developer) list > please ignore or guide me to a more appropriate list (it is possibly more of > an end user question). > Is it possible to debug Visual Studio generated (with pdb debug info) > executables (2017 or 2019, C++ only) with lldb? LLDB does have PDB parsing abilities, though I am unsure how well they work out of the box with no extra configuration. There are two PDB parsers in LLDB at the moment, one that uses a DLL from Visual Studio that knows how to parse a PDB file, and one that tries to parse the PDB file manually. So if you are natively on windows, I believe you might need to set run the batch file that sets up environment variables for finding these DLLs. The native PDB parser should work, but I am not sure if the native version always takes precedence when running on the Windows OS. Maybe someone that did the PDB integration could chime in? > And if so is there a full integration into eclipse so i can debug Visual > Studio generated executable with eclipse? The only integration that I am aware of was one that used lldb-mi, or the GDB remote machine interface. But the lldb-mi was dropped from the top of tree LLDB a while ago because it was not tested and was bit rotting. We do have a lldb-vscode binary that implements the Microsoft Visual Studio Code DAP (Debug Adaptor Protocol). If there are any Eclipse plug-ins that integrated with the VS Code DAP plug-ins, that would be the option I would suggest looking into. Is using Visual Studio Code an option, or only Eclipse? > The platform in question is Microsoft Windows 10 (recent versions). > > Thx in advance > > Franz > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb versus visual studio
Thank you very much, this essentially meets my expectations (no eclipse debugging with Windows/VC++), i am a little surprised that there is no working lldb integration for eclipse, is this really the whole truth (or did i misunderstand)? Am 22.03.2021 um 19:28 schrieb Greg Clayton: On Mar 20, 2021, at 8:57 AM, Franz Fehringer via lldb-dev wrote: Dear lldb-dev community, First a disclaimer: If my question is inappropriate for this (developer) list please ignore or guide me to a more appropriate list (it is possibly more of an end user question). Is it possible to debug Visual Studio generated (with pdb debug info) executables (2017 or 2019, C++ only) with lldb? LLDB does have PDB parsing abilities, though I am unsure how well they work out of the box with no extra configuration. There are two PDB parsers in LLDB at the moment, one that uses a DLL from Visual Studio that knows how to parse a PDB file, and one that tries to parse the PDB file manually. So if you are natively on windows, I believe you might need to set run the batch file that sets up environment variables for finding these DLLs. The native PDB parser should work, but I am not sure if the native version always takes precedence when running on the Windows OS. Maybe someone that did the PDB integration could chime in? And if so is there a full integration into eclipse so i can debug Visual Studio generated executable with eclipse? The only integration that I am aware of was one that used lldb-mi, or the GDB remote machine interface. But the lldb-mi was dropped from the top of tree LLDB a while ago because it was not tested and was bit rotting. We do have a lldb-vscode binary that implements the Microsoft Visual Studio Code DAP (Debug Adaptor Protocol). If there are any Eclipse plug-ins that integrated with the VS Code DAP plug-ins, that would be the option I would suggest looking into. Is using Visual Studio Code an option, or only Eclipse? The platform in question is Microsoft Windows 10 (recent versions). Thx in advance Franz ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb versus visual studio
There was. Almost nobody used it. Nobody maintained it. > -Original Message- > From: lldb-dev On Behalf Of Franz > Fehringer via lldb-dev > Sent: Monday, March 22, 2021 2:28 PM > To: lldb-dev@lists.llvm.org > Subject: [EXT] Re: [lldb-dev] lldb versus visual studio > > Thank you very much, this essentially meets my expectations (no eclipse > debugging with Windows/VC++), i am a little surprised that there is no > working lldb integration for eclipse, is this really the whole truth (or did i > misunderstand)? > > > Am 22.03.2021 um 19:28 schrieb Greg Clayton: > > > >> On Mar 20, 2021, at 8:57 AM, Franz Fehringer via lldb-dev d...@lists.llvm.org> wrote: > >> > >> Dear lldb-dev community, > >> > >> First a disclaimer: If my question is inappropriate for this (developer) > >> list > please ignore or guide me to a more appropriate list (it is possibly more of > an > end user question). > >> Is it possible to debug Visual Studio generated (with pdb debug info) > executables (2017 or 2019, C++ only) with lldb? > > LLDB does have PDB parsing abilities, though I am unsure how well they > work out of the box with no extra configuration. There are two PDB parsers > in LLDB at the moment, one that uses a DLL from Visual Studio that knows > how to parse a PDB file, and one that tries to parse the PDB file manually. So > if you are natively on windows, I believe you might need to set run the batch > file that sets up environment variables for finding these DLLs. The native PDB > parser should work, but I am not sure if the native version always takes > precedence when running on the Windows OS. > > > > Maybe someone that did the PDB integration could chime in? > > > > > >> And if so is there a full integration into eclipse so i can debug Visual > >> Studio > generated executable with eclipse? > > The only integration that I am aware of was one that used lldb-mi, or the > GDB remote machine interface. But the lldb-mi was dropped from the top of > tree LLDB a while ago because it was not tested and was bit rotting. > > > > We do have a lldb-vscode binary that implements the Microsoft Visual > Studio Code DAP (Debug Adaptor Protocol). If there are any Eclipse plug-ins > that integrated with the VS Code DAP plug-ins, that would be the option I > would suggest looking into. Is using Visual Studio Code an option, or only > Eclipse? > > > >> The platform in question is Microsoft Windows 10 (recent versions). > >> > >> Thx in advance > >> > >> Franz > >> > >> ___ > >> lldb-dev mailing list > >> lldb-dev@lists.llvm.org > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb versus visual studio
Thx again Am 22.03.2021 um 21:55 schrieb Ted Woodward: There was. Almost nobody used it. Nobody maintained it. -Original Message- From: lldb-dev On Behalf Of Franz Fehringer via lldb-dev Sent: Monday, March 22, 2021 2:28 PM To: lldb-dev@lists.llvm.org Subject: [EXT] Re: [lldb-dev] lldb versus visual studio Thank you very much, this essentially meets my expectations (no eclipse debugging with Windows/VC++), i am a little surprised that there is no working lldb integration for eclipse, is this really the whole truth (or did i misunderstand)? Am 22.03.2021 um 19:28 schrieb Greg Clayton: On Mar 20, 2021, at 8:57 AM, Franz Fehringer via lldb-dev d...@lists.llvm.org> wrote: Dear lldb-dev community, First a disclaimer: If my question is inappropriate for this (developer) list please ignore or guide me to a more appropriate list (it is possibly more of an end user question). Is it possible to debug Visual Studio generated (with pdb debug info) executables (2017 or 2019, C++ only) with lldb? LLDB does have PDB parsing abilities, though I am unsure how well they work out of the box with no extra configuration. There are two PDB parsers in LLDB at the moment, one that uses a DLL from Visual Studio that knows how to parse a PDB file, and one that tries to parse the PDB file manually. So if you are natively on windows, I believe you might need to set run the batch file that sets up environment variables for finding these DLLs. The native PDB parser should work, but I am not sure if the native version always takes precedence when running on the Windows OS. Maybe someone that did the PDB integration could chime in? And if so is there a full integration into eclipse so i can debug Visual Studio generated executable with eclipse? The only integration that I am aware of was one that used lldb-mi, or the GDB remote machine interface. But the lldb-mi was dropped from the top of tree LLDB a while ago because it was not tested and was bit rotting. We do have a lldb-vscode binary that implements the Microsoft Visual Studio Code DAP (Debug Adaptor Protocol). If there are any Eclipse plug-ins that integrated with the VS Code DAP plug-ins, that would be the option I would suggest looking into. Is using Visual Studio Code an option, or only Eclipse? The platform in question is Microsoft Windows 10 (recent versions). Thx in advance Franz ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] RFC: packet to identify a standalone aka firmware binary UUID / location
Hi, I'm working with an Apple team that has a gdb RSP server for JTAG
debugging, and we're working to add the ability for it to tell lldb about the
UUID and possibly address of a no-dynamic-linker standalone binary, or firmware
binary. Discovery of these today is ad-hoc and each different processor has a
different way of locating the main binary (and possibly sliding it to the
correct load address).
We have two main ways of asking the remote stub about binary images today:
jGetLoadedDynamicLibrariesInfos on Darwin systems with debugserver, and
qXfer:libraries-svr4: on Linux.
jGetLoadedDynamicLibrariesInfos has two modes: "tell me about all libraries"
and "tell me about libraries at these load addresses" (we get notified about
libraries being loaded/unloaded as a list of load addresses of the binary
images; binaries are loaded in waves on a Darwin system). The returned JSON
packet is heavily tailored to include everything lldb needs to know about the
binary image so it can match a file it finds on the local disk to the
description and not read any memory at debug time -- we get the mach-o header,
the UUID, the deployment target OS version, the load address of all the
segments. The packets lldb sends to debugserver look like
jGetLoadedDynamicLibrariesInfos:{"fetch_all_solibs":true}
or
jGetLoadedDynamicLibrariesInfos:{"solib_addresses":[4294967296,140733735313408,..]}
qXfer:libraries-svr4: returns an XML description of all binary images loaded,
tailored towards an ELF view of binaries from a brief skim of ProcessGDBRemote.
I chose not to use this because we'd have an entirely different set of values
returned in our xml reply for Mach-O binaries and to eliminate extraneous read
packets from lldb, plus we needed a way of asking for a subset of all binary
images. A rich UI app these days can link to five hundred binary images, so
fetching the full list when only a couple of binaries was just loaded would be
unfortunate.
I'm trying to decide whether to (1) add a new qStandaloneBinaryInfo packet
which returns the simple gdb RSP style "uuid:;address:0xADDR;" response,
or (2) if we add a third mode to jGetLoadedDynamicLibrariesInfos
(jGetLoadedDynamicLibrariesInfos:{"standalone_binary_image_info":true}) or (3)
have the JTAG stub support a qXfer XML request (I wouldn't want to reuse the
libraries-svr4 name and return an XML completely different, but it could have a
qXfer:standalone-binary-image-info: or whatever).
I figured folks might have opinions on this so I wanted to see if anyone cares
before I pick one and get everyone to implement it. For me, I'm inclined
towards adding a qStandaloneBinaryInfo packet - the jtag stub already knows how
to construct these traditional gdb RSP style responses - but it would be
trivially easy for the stub to also assemble a fake XML response as raw text
with the two fields.
J
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
