Re: [lldb-dev] who is maintaining lldb-x86_64-debian
On Thu, 02 Sep 2021 12:42:37 +0200, Raphael “Teemperor” Isemann via lldb-dev wrote: > If this is about the TestGuiBasicDebug failures, then that test is also > failing on other bots. I personally would vote to disable the test as that > part of the test is flakey since its introduction (which was during this > GSoC). There are multiple racy testcases. I have setup alert only if all last 5 builds failed. That is a longterm reliable enough threshold. For https://lab.llvm.org/staging/#/builders/16 = lldb-x86_64-fedora: https://lab.llvm.org/staging/api/v2/builders/16/builds?limit=5=-number "state_string": "build successful", Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] proposed change to remove conditional WCHAR support in libedit wrapper
On Sun, 11 Jul 2021 14:49:25 +0200, Raphael “Teemperor” Isemann via lldb-dev wrote: > LLDB also provides a custom callback for libedit to read characters from the > command line (which mariadb probably doesn’t), so maybe we implemented that > incorrectly. Missing setlocale(), filed it as: RFC: [lldb] Fix editline unicode on Linux https://reviews.llvm.org/D105779 Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] proposed change to remove conditional WCHAR support in libedit wrapper
On Sun, 11 Jul 2021 13:07:26 +0200, Raphael “Teemperor” Isemann wrote: > What libedit version/port is Fedora using? > [1] https://thrysoee.dk/editline/ Source RPM : libedit-3.1-37.20210522cvs.fc34.src.rpm URL : https://www.thrysoee.dk/editline/ > I think the usual Linux port[1] is suffering from two issues: The question is why the same libedit library on the same OS works with mariadb client. Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] proposed change to remove conditional WCHAR support in libedit wrapper
On Sun, 11 Jul 2021 11:11:02 +0200, Jan Kratochvil via lldb-dev wrote: > OTOH the wide character does not work there and even not on Fedora 34 x86_64: > typing: žščř > (lldb) \U+017E\U+0161\U+010D\U+0159 > error: 'žščř' is not a valid command. > typing: áéíóůúý > (lldb) \U+016F > error: 'ů' is not a valid command. > > While mariadb client works fine on Fedora 34 x86_64: > MariaDB [(none)]> žščřáéíóůúý; > ERROR 1064 (42000): You have an error in your SQL syntax; check the manual > that corresponds to your MariaDB server version for the right syntax to use > near 'žščřáéíóůúý' at line 1 > > Do you have an idea what can be wrong in LLDB? I forgot to check OSX lldb which does work so I will have to find it out myself: Apple Swift version 5.4.2 (swiftlang-1205.0.28.2 clang-1205.0.19.57) (lldb) žščř error: 'žščř' is not a valid command. Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] proposed change to remove conditional WCHAR support in libedit wrapper
On Sat, 10 Jul 2021 10:51:34 +0200, Neal Sidhwaney via lldb-dev wrote: > Anyone else think this could be useful? Or, conversely, does anyone see > something that I missed that requires the conditional compilation to remain > in? Oldest platform Red Hat builds LLDB on is RHEL-7 (and its copies) and it already contains el_winsertstr and your branch builds fine there. https://copr.fedorainfracloud.org/coprs/jankratochvil/lldb/build/2321456/ OTOH the wide character does not work there and even not on Fedora 34 x86_64: typing: žščř (lldb) \U+017E\U+0161\U+010D\U+0159 error: 'žščř' is not a valid command. typing: áéíóůúý (lldb) \U+016F error: 'ů' is not a valid command. While mariadb client works fine on Fedora 34 x86_64: MariaDB [(none)]> žščřáéíóůúý; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'žščřáéíóůúý' at line 1 Do you have an idea what can be wrong in LLDB? Thanks, Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] buildbot slave able to run on python3
Hi Galina, there was: [llvm-dev] Buildbot cleaning for zorg upgrade https://lists.llvm.org/pipermail/llvm-dev/2020-February/139503.html "Zorg upgrade to a recent version of buildbot is coming." Do I understand it correctly there is a plan we could start using buildbot-2.x which is protocol-incompatible with the current buildbot-0.8.5 in use? buildbot-0.8.5 supports only python-2 (not python-3). Fedora 32 and higher no longer support python-2. I am stuck how to support recent Fedoras for buildbot. buildbot-0.9.0 started to support python-3 but I guess buildbot-0.9.0 is no longer protocol-compatible with LLVM buildbot master. I have tried 0.9.0 but it does not run on Fedora 32 (due to incompatible python-3 libraries) so I would need to use some even newer buildbot version which I assume to be definitely protocol-incompatible. Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Setting breakpoint on file and function name doesn't work as expected.
On Mon, 04 Nov 2019 16:16:30 +0100, Konrad Kleine via lldb-dev wrote:
> I read the LLDB troubleshooting page [1] and found interesting quotes:
>
> > When setting breakpoints in implementation source files (.c, cpp, cxx,
> .m, .mm, etc), LLDB by
> > default will only search for compile units whose filename matches.
> > [...]
> > % echo "settings set target.inline-breakpoint-strategy always" >>
> ~/.lldbinit
...
> I now added the breakpoint strategy and ran the above command without the
> -x in order to pick up
> the LLDB init code. Still no luck.
That doc is obsolete, LLDB has this setting by default:
(lldb) settings show target.inline-breakpoint-strategy
target.inline-breakpoint-strategy (enum) = always
It has been changed:
https://github.com/llvm/llvm-project/commit/ad6eee639952090684aa84c35218ec327a017ca1
This setting does work but only for the --line option:
==> inc.C <==
#include "inc2.C"
int main() {
func();
}
==> inc2.C <==
static volatile int i;
static void func() {
i++;
}
$ clang++ -o inc inc.C -Wall -g;lldb ./inc
(lldb) target create "./inc"
Current executable set to './inc' (x86_64).
(lldb) settings set target.inline-breakpoint-strategy headers
(lldb) breakpoint set --file inc2.C --line 3
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) settings set target.inline-breakpoint-strategy always
(lldb) breakpoint set --file inc2.C --line 3
Breakpoint 2: where = inc`func() + 4 at inc2.C:3:4, address = 0x00401124
(lldb) _
To make it working also for the -n option will require some fix, maybe some
code around lldb/source/Commands/CommandObjectBreakpoint.cpp line 500, dunno.
Jan
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] RFC: DWZ = DW_TAG_imported_unit + separate DWARF common file
Hi,
I would like to get a design approval before I do all remaining technical
cleanups of (3) below.
It was discussed before at:
[lldb-dev] RFC for DWZ = DW_TAG_imported_unit + DWARF-5 supplementary
files
https://lists.llvm.org/pipermail/lldb-dev/2017-August/012656.html
Message-ID: <20170823210611.ga8...@host1.jankratochvil.net>
DWZ principle: DW_TAG_compile_unit can use DW_TAG_imported_unit to "include"
some other DW_TAG_partial_unit. This can happen transitively==recursively.
Unfortunately DW_TAG_partial_unit does not contain DW_AT_language so for
GetLanguageType() LLDB needs to read DW_TAG_compile_unit which included it
and read its DW_AT_language there. Two DW_TAG_compile_unit's with different
DW_AT_language can include (=DW_TAG_imported_unit) the same DW_TAG_partial_unit.
(1) Originally I tried to create 1:1 DWARFCompileUnit mapping to
DW_TAG_partial_unit. This did not work as each DWARFCompileUnit gets
mapped to CompileUnit and multiple CompileUnit's in the same block lead to:
Assertion `!Parent || >getParentASTContext() == ' failed.
(2) Then I tried creating N:1 DWARFCompileUnit's for each DW_TAG_partial_unit,
that is a 1:1 DWARFCompileUnit for each DW_TAG_imported_unit "inclusion".
That worked perfectly but it was considered needlessly ineffective:
[Lldb-commits] [PATCH] D45170: Cleanup DWARFCompileUnit and DWARFUnit in
preparation for adding DWARFTypeUnit
https://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20180409/040211.html
It was mapping each DW_TAG_partial_unit from its DWARFFileOffset to
a new virtual dw_offset_t by MainCU_FileOffsetToCU():
https://reviews.llvm.org/D40474?id=138860
It needed to remap dw_offset_t back to DWARFFileOffset to read
DWARFUnit::m_die_array without a data copy for each DW_TAG_imported_unit.
(3)
My current patch proposal is to create 1:1 DWARFPartialUnit (*1) mapping to
DW_TAG_partial_unit. To support GetLanguageType() for DWARFPartialUnit one
must track the original DWARFCompileUnit * (DW_TAG_compile_unit) in any
DIERef or DWARFBaseDIE. DWARFPartialUnit itself can be used by multiple
DWARFCompileUnit's. I have replaced 'DWARFUnit *' at many places by:
class DWARFUnitPair { DWARFUnit *m_cu; DWARFCompileUnit *m_main_cu; };
(*1) There is no DWARFPartialUnit, DW_TAG_partial_unit is represented by
DWARFCompileUnit. During scanning of CUs it is too expensive to read the
first DIE whether it is DW_TAG_compile_unit or DW_TAG_partial_unit.
DWARFPartialUnit would make sense with DWARF-5 DWZ DW_UT_partial but the
current only existing DWZ tool does not support DWARF-5 yet.
Therefore any AST contexts are made only for DW_TAG_compile_unit,
DW_TAG_partial_unit never has its own AST context. Also any
DW_TAG_partial_unit DIEs are duplicated as AST for each use of
DW_TAG_imported_unit. I hope I did not miss some such more optimal possibility
but I prefer to decompress DWZ on DWARF level than on AST level as the DWZ
tool also does not interpret much the DWARF data when finding common DWARF
DIEs.
Stays the same for as once instance for DW_TAG_partial_unit:
DWARFDebugInfoEntry: no DWARFUnit reference, kept intact
sizeof(): stays 16
Gets duplicated for each DW_TAG_imported_unit:
DWARFBaseDIE: DWARFUnit *m_cu, DWARFDebugInfoEntry *m_die,
now added also: DWARFCompileUnit *m_main_cu (in DWARFUnitPair)
sizeof(): 16 -> 24 (new DWARFCompileUnit *m_main_cu)
Only DWARFTypeUnit DIEs must have DWARFCompileUnit *m_main_cu as nullptr,
they contain DW_AT_language so m_main_cu is not really needed for them.
DIERef sizeof(): stays 8 (it now remembers parent DWARFCompileUnit's index)
Only for temporary variables:
new DWARFSimpleDIE: DWARFUnit *m_cu, DWARFDebugInfoEntry *m_die
- it is like original DWARFBaseDIE for a few cases (like Reference())
where I need DWARFUnit *m_cu but DWARFCompileUnit *m_main_cu is not known.
- DWARFSimpleDIE is now standalone, maybe DWARFBaseDIE could inherit it?
Some functions needing parent DWARFCompileUnit *m_main_cu were moved from
DWARFUnit to DWARFCompileUnit: LookupAddress, AppendDIEsWithTag,
GetTypeSystem, GetLanguageType, GetUnitDIEOnly, DIE, GetDIE,
git remote add jankratochvil git://git.jankratochvil.net/lldb
git fetch jankratochvil
git checkout jankratochvil/dwz
or:
git clone -b dwz git://git.jankratochvil.net/lldb
Full patch:
https://people.redhat.com/jkratoch/dwz-2019-10-30.patch
Patch part showing the usage of DWARFUnitPair:
https://people.redhat.com/jkratoch/dwz-DWARFUnitPair-2019-10-30.patch
Thanks,
Jan
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Offline build bots
On Sat, 12 Oct 2019 00:06:01 +0200, António Afonso via lldb-dev wrote:
> All the *nix build bots (lldb-x86_86-{debian,fedora}, netbsd-amd64) have
> been offline for a while now. Some as far as July 12.
> I’m not sure if this is being tracked or whom to contact about this.
lldb-x86_64-fedora runs as silent buildbot:
http://lab.llvm.org:8014/builders/lldb-x86_64-fedora?numbuilds=1000
Yes, the buildbot is failing now all the time for a week+, I need to debug it.
I do not see these failures on my own Fedora development box.
When it had no failures it still had occasional failure due to some testcases
being racy (for example TestVSCode_attach besides others) so I did not want to
bugreport people by false positives. Developers do not see much these racy
results as this buildbot runs on both poor machine and also the machine is
overloaded even by unrelated jobs.
There are now also the following two silent buildbots but those always fail
now due to some testcases needing fixing (or rather
@expectedFailureAll-marking) for these s390x+ppc64le arches:
http://lab.llvm.org:8014/builders/lldb-s390x-fedora?numbuilds=100
http://lab.llvm.org:8014/builders/lldb-ppc64le-fedora?numbuilds=100
Jan
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")
On Tue, 08 Oct 2019 15:42:25 +0200, Pavel Labath wrote: > On 08/10/2019 10:14, Jan Kratochvil wrote: > > If I should say something I would keep llvm::. > > > > My reason: The LLVM types are in many cases emulating classes adopted > > in future C++ standards and I find more clear llvm:: vs. std:: than > > "" vs. std::. Moreover when std:: is commonly omitted in other projects. > > Which classes do you have in mind exactly? I know a lot of llvm *functions* > mimic similar std:: versions, but I can't think of any *classes* right now. > thinking here mainly of ADT classes like String/ArrayRef, Optional/Error, llvm::StringRef vs. std::string, llvm::Optional vs. std::optional. I do not want to argue whether it is ambiguous or not but you asked for an +1/-1 opinion. Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")
On Wed, 17 Apr 2019 12:39:51 +0200, Pavel Labath via lldb-dev wrote: > some llvm classes, are so well-known and widely used, that qualifying them > with "llvm::" serves no useful purpose and only adds visual noise. I'm > thinking here mainly of ADT classes like String/ArrayRef, Optional/Error, > etc. I propose we stop explicitly qualifying these classes. ... > What do you think? If I should say something I would keep llvm::. My reason: The LLVM types are in many cases emulating classes adopted in future C++ standards and I find more clear llvm:: vs. std:: than "" vs. std::. Moreover when std:: is commonly omitted in other projects. Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] STABS
On Fri, 26 Jul 2019 13:42:59 +0200, Pavel Labath via lldb-dev wrote: > Is anyone still using STABS debug info? If not, can we remove it? I have now found just: Re: stabs changes for 64 bit targets https://sourceware.org/ml/gdb/2013-05/msg00057.html "AIX continues to use STABS with its XCOFF file format" And then IBM is porting LLVM to AIX: [llvm-dev] [RFC] Adding LLVM Support for AIX https://lists.llvm.org/pipermail/llvm-dev/2019-February/130175.html But who knows whether AIX is still using STABS nowdays (Cced)? Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Access to TLS variables on GNU/Linux
On Tue, 14 May 2019 13:38:57 +0200, Florian Weimer via lldb-dev wrote:
> The target process has loaded libpthread.so.0, so it's not the usual
> problem of libthread_db not working without libpthread.
>
> On the other hand, I realize now that the lldb command cannot access TLS
> variables, either. Is this expected to work at all?
TLS is implemented only for FreeBSD as there is
FreeBSDThread::GetThreadPointer() but on Linux it falls back to unimplemented:
lldb::addr_t Thread::GetThreadPointer() { return LLDB_INVALID_ADDRESS; }
On Linux it uses DynamicLoaderPOSIXDYLD::GetThreadLocalData() which may work
without libthread_db as it is reading "_thread_db_*" symbols in
DYLDRendezvous::GetThreadInfo(). But it needs that GetThreadPointer() which
could get implemented (for x86_64) by reading %fs_base. LLDB currently does
not know anything about %fs_base+%gs_base.
Is it a good idea to implement %fs_base+%gs_base to make TLS working on Linux?
Jan
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Test suite failures on Fedora Linux?
On Mon, 25 Mar 2019 19:47:36 +0100, David Zarzycki via lldb-dev wrote: > Also, given that two of the test failures are Intel specific (the mxcsr > register write failures), what class of hardware do you use? My workstation > is Skylake-SP based, if it matters. OK, I agree it PASSes for me on Haswell-EP (E5-2630v3) but it also FAILs for me on Kaby Lake Refresh (i7-8650U). Also kernel-5.0.3-200.fc29.x86_64. Jan [ 0%] Built target LLVMDemangle [ 0%] Built target LLVMTableGen [ 0%] Built target LLVMBinaryFormat [ 0%] Built target LLVMMCParser [ 0%] Built target llvm_vcsrevision_h [ 0%] Built target LLVMObjectYAML [ 0%] Built target LLVMDebugInfoMSF [ 0%] Built target count [ 1%] Built target obj.llvm-tblgen [ 1%] Built target LLVMDebugInfoCodeView [ 3%] Built target LLVMMC [ 3%] Built target obj.clang-tblgen [ 3%] Built target LLVMOption [ 6%] Built target LLVMSupport [ 6%] Built target LLVMMCDisassembler [ 6%] Built target LLVMWindowsManifest [ 6%] Built target lldReaderWriter [ 6%] Built target lldYAML [ 6%] Built target liblldb_exports [ 6%] Built target swig_wrapper [ 6%] Built target lldMachO [ 6%] Built target gtest_main [ 6%] Built target gtest [ 8%] Built target LLVMDebugInfoDWARF [ 8%] Built target readline [ 8%] Built target lldb-mi-utils [ 8%] Built target environment_check [ 8%] Built target llvm-tblgen [ 8%] Built target thread_inferior [ 8%] Built target clang-tblgen [ 8%] Built target FileCheck [ 8%] Built target llvm-config [ 10%] Built target LLVMDebugInfoPDB [ 10%] Built target LLVMTestingSupport [ 10%] Built target not [ 10%] Built target LLDBMiUtilTests [ 10%] Built target intrinsics_gen [ 10%] Built target ClangSACheckers [ 10%] Built target AttributeCompatFuncTableGen [ 10%] Built target ClangAttrVisitor [ 10%] Built target ClangStmtNodes [ 10%] Built target StmtDataCollectors [ 10%] Built target ClangAttrTextDump [ 10%] Built target ClangAttrTraverse [ 10%] Built target ClangAttrClasses [ 10%] Built target ClangAttrImpl [ 10%] Built target ClangDeclNodes [ 10%] Built target ClangCommentHTMLTagsProperties [ 10%] Built target ClangCommentCommandList [ 10%] Built target ClangCommentCommandInfo [ 10%] Built target ClangCommentHTMLNamedCharacterReferences [ 10%] Built target ClangCommentHTMLTags [ 10%] Built target ClangCommentNodes [ 10%] Built target ClangARMFP16 [ 10%] Built target ClangARMNeon [ 10%] Built target ClangAttrHasAttributeImpl [ 10%] Built target ClangDiagnosticCrossTU [ 10%] Built target ClangAttrList [ 10%] Built target ClangDiagnosticCommon [ 10%] Built target ClangDiagnosticAST [ 10%] Built target ClangDiagnosticAnalysis [ 10%] Built target ClangDiagnosticFrontend [ 10%] Built target ClangDiagnosticSema [ 10%] Built target ClangDiagnosticDriver [ 10%] Built target ClangDiagnosticLex [ 10%] Built target ClangDiagnosticRefactoring [ 10%] Built target ClangDiagnosticParse [ 10%] Built target ClangDiagnosticGroups [ 10%] Built target ClangDiagnosticSerialization [ 10%] Built target ClangDiagnosticIndexName [ 10%] Built target ClangAttrSubjectMatchRuleList [ 10%] Built target ClangDiagnosticComment [ 10%] Built target ClangAttrTemplateInstantiate [ 10%] Built target ClangAttrSubMatchRulesParserStringSwitches [ 10%] Built target ClangAttrParsedAttrImpl [ 10%] Built target ClangAttrSpellingListIndex [ 10%] Built target ClangAttrParserStringSwitches [ 10%] Built target ClangAttrParsedAttrList [ 10%] Built target ClangAttrParsedAttrKinds [ 10%] Built target ClangAttrPCHWrite [ 10%] Built target ClangAttrPCHRead [ 10%] Built target LLVMBitWriter [ 10%] Built target LLVMIRReader [ 10%] Built target LLVMProfileData [ 10%] Built target LLVMMIRParser [ 10%] Built target LLVMAggressiveInstCombine [ 10%] Built target LLVMSelectionDAG [ 10%] Built target LLVMInstrumentation [ 10%] Built target LLVMAsmPrinter [ 10%] Built target LLVMGlobalISel [ 10%] Built target InstCombineTableGen [ 11%] Built target LLVMTransformUtils [ 15%] Built target LLVMAnalysis [ 15%] Built target LLVMVectorize [ 15%] Built target LLVMObjCARCOpts [ 16%] Built target LLVMLinker [ 16%] Built target LLVMCoroutines [ 18%] Built target LLVMTarget [ 18%] Built target AArch64CommonTableGen [ 18%] Built target LLVMLTO [ 18%] Built target LLVMipo [ 18%] Built target ARMCommonTableGen [ 18%] Built target BPFCommonTableGen [ 18%] Built target AMDGPUCommonTableGen [ 20%] Built target LLVMScalarOpts [ 20%] Built target LanaiCommonTableGen [ 20%] Built target MipsCommonTableGen [ 20%] Built target MSP430CommonTableGen [ 20%] Built target NVPTXCommonTableGen [ 20%] Built target HexagonCommonTableGen [ 20%] Built target PowerPCCommonTableGen [ 20%] Built target XCoreCommonTableGen [ 20%] Built target SystemZCommonTableGen [ 20%] Built target SparcCommonTableGen [ 20%] Built target LLVMAsmParser [ 20%] Built target WebAssemblyCommonTableGen [ 20%] Built target LLVMCoverage [ 21%] Built target X86CommonTableGen [ 21%] Built target LLVMPasses [ 25%] Built target clang-resource-headers [ 25%] Built
Re: [lldb-dev] Test suite failures on Fedora Linux?
On Mon, 25 Mar 2019 14:11:09 +0100, David Zarzycki via lldb-dev wrote: > 5.0.3-200.fc29.x86_64 (mockbu...@bkernel03.phx2.fedoraproject.org) (gcc > version 8.3.1 20190223 (Red Hat 8.3.1-2) (GCC)) #1 SMP Tue Mar 19 15:07:58 > UTC 2019 It does PASS here on: kernel-5.0.3-200.fc29.x86_64 LLVM monorepo b833c6af5911ca71c555771097a03643660c1643 Failing Tests (1): lldb-Suite :: functionalities/register/intel_avx/TestYMMRegister.py Expected Passes: 1517 Expected Failures : 1 Unsupported Tests : 31 Unexpected Failures: 1 That TestYMMRegister.py happens for me only in KVM virtualization guest, unrelated to kernel version. I have never tried LLDB testsuite in KVM before, I guess it is a KVM bug. https://github.com/llvm/llvm-project.git time cmake ../llvm-monorepo/llvm/ -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold -DLLVM_ENABLE_PROJECTS="lldb;clang;lld" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DLLVM_ENABLE_ASSERTIONS=ON make;make check-lldb Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Test suite failures on Fedora Linux?
On Mon, 25 Mar 2019 12:05:33 +0100, David Zarzycki via lldb-dev wrote: > I’m trying to build/test/run the latest lldb on the latest Red Hat Fedora, > but I’m seeing four failures. Is this expected? What operating system do the > LLVM build bots run? Thanks! My Fedora buildbot does run Fedora 29 x86_64 but it is a bit underpowered so several racy testcases fail there, I need to fix those: http://lab.llvm.org:8014/buildslaves/lldb-x86_64-fedora On my normal workstation I get PASS (9ac2859cf2f2a47c8ec66ad4771bb35d627a789f). kernel-4.20.15-200.fc29.x86_64 Testing Time: 82.61s Expected Passes: 1535 Expected Failures : 1 Unsupported Tests : 31 [100%] Built target check-lldb As a form of troubleshooting you can try: # dnf install elfutils-default-yama-scope;echo 0 >/proc/sys/kernel/yama/ptrace_scope;setenforce 0 Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Status of DWARF64 in LLDB
On Mon, 11 Mar 2019 21:25:05 +0100, Jan Kratochvil via lldb-dev wrote: > I think it is never needed in real world as long as one uses DWP and/or > -fdebug-types-section. Red Hat is using neither (for DWZ postprocessing) and > so I did hit this limit of unsupported DWARF64 in GNU utilities [attached]. FYI chromium-67.0.3396.87.rpm built with gcc-8.3.1-2.fc29.x86_64 DWARF-4 -fdebug-types-section has 1.6GB .debug_info and 0.5GB .debug_types: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [30] .debug_aranges PROGBITS 000360 7a7630 00 0 0 16 [31] .debug_infoPROGBITS 7a7990 5e358d47 00 0 0 1 [32] .debug_abbrev PROGBITS 5eb006d7 716d053 00 0 0 1 [33] .debug_linePROGBITS 65c6d72a c686a97 00 0 0 1 [34] .debug_str PROGBITS 722f41c1 21c96669 01 MS 0 0 1 [35] .debug_loc PROGBITS 93f8a82a 24b3a638 00 0 0 1 [36] .debug_ranges PROGBITS b8ac4e62 ec29fd0 00 0 0 1 [37] .debug_types PROGBITS c76eee32 1cab0bd3 00 0 0 1 Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Status of DWARF64 in LLDB
On Mon, 11 Mar 2019 20:45:48 +0100, Zachary Turner via lldb-dev wrote:
> I want to ask what the status of DWARF64 in LLDB is.
IMO there isn't as for example:
lldb/source/Plugins/SymbolFile/DWARF/DIERef.cpp
is using bits 32..63 for additional info (DWO file offset/index for example)
while only bits 0..31 are used for DIE offset inside .debug_info section.
lldb/include/lldb/Core/dwarf.h
#ifdef DWARFUTILS_DWARF64
but nobody ever defines DWARFUTILS_DWARF64 and so it uses:
typedef uint32_t dw_offset_t; // Dwarf Debug Information Entry offset for any
// offset into the file
> For example, I > know that clang and LLVM will not even generate DWARF64,
Even GCC needs to be patched to generate DWARF64.
> Certainly we can improve LLVM's support for consuming DWARF64, but it's a
> question of priorities.
I think it is never needed in real world as long as one uses DWP and/or
-fdebug-types-section. Red Hat is using neither (for DWZ postprocessing) and
so I did hit this limit of unsupported DWARF64 in GNU utilities [attached].
Jan
--- Begin Message ---
Hello,
LLDB people were talking about 6GB Chromium binaries. So I checked Fedora
Chromium but:
# Debuginfo packages aren't very useful here. If you need to debug
# you should do a proper debug build (not implemented in this spec yet)
%global debug_package %{nil}
and it uses no '-g' during compilation.
After enabling Chromium debug info [attached, it has only -g2, not -g3] I got:
obj/mojo/public/cpp/system/system/message_pipe.o:(.debug_loc+0x1bcc):
relocation truncated to fit: R_X86_64_32 against `.debug_info'
...
obj/third_party/blink/renderer/platform/platform/fe_convolve_matrix.o:(.debug_info+0x4b5dc):
additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
Which is logical as Chromium has 8GB of .debug_info section. I found no gcc
option to enable 64-bit DWARF so I had to patch GCC for that [attached].
But then the rpmbuild failed a different way:
/usr/lib/rpm/debugedit:
BUILDROOT/chromium-67.0.3396.87-2.fc28.x86_64/usr/lib64/chromium-browser/libEGL.so:
64-bit DWARF not supported
...
eu-strip: elf32_updatefile.c:336: __elf64_updatemmap: Assertion
`dl->data.d.d_size <= (shdr->sh_size - (GElf_Off) dl->data.d.d_off)' failed.
/usr/lib/rpm/find-debuginfo.sh: line 231: 3998449 Aborted
eu-strip --remove-comment $r $g ${keep_remove_args} -f "$1" "$2"
double free or corruption (out)
/usr/lib/rpm/find-debuginfo.sh: line 231: 3998529 Aborted
eu-strip --remove-comment $r $g ${keep_remove_args} -f "$1" "$2"
dwz:
./etc/chromium/native-messaging-hosts/remoting_user_session-67.0.3396.87-2.fc28.x86_64.debug:
64-bit DWARF not supported
DWZ would be unable to handle it on x86_64 even if it did support DWARF64 as
rpmbuild limits it to 110e6 DIEs while this DWARF has 500e6 DIEs.
Google AFAIK builds it with -gsplit-dwarf and then one can pack the *.dwo
files into EXEC.dwp by /usr/bin/dwp (llvm-dwp in the Google case).
DWZ-like optimization is then achieved by -fdebug-types-section.
But then rpmbuild is not prepared to handle *.dwp (like current *.debug).
The 10GB DWARF64 binary if anyone is interested:
https://www.jankratochvil.net/t/chromium-headless_shell.xz
Then it is questionable whether to deal with DWARF64/DWP just for Chromium.
Customers really do not have binaries of this DWARF size?
Jan
diff --git a/gcc/defaults.h b/gcc/defaults.h
index 9035b333be8..ec4fce27395 100644
--- a/gcc/defaults.h
+++ b/gcc/defaults.h
@@ -458,7 +458,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If not, see
DWARF-2 specification. The SGI/MIPS ABI defines it to be the same
as PTR_SIZE. */
#ifndef DWARF_OFFSET_SIZE
-#define DWARF_OFFSET_SIZE 4
+#define DWARF_OFFSET_SIZE PTR_SIZE
#endif
/* The size in bytes of a DWARF 4 type signature. */
diff --git a/chromium.spec b/chromium.spec
index a2f2d93..a34b636 100644
--- a/chromium.spec
+++ b/chromium.spec
@@ -16,7 +16,7 @@
# Debuginfo packages aren't very useful here. If you need to debug
# you should do a proper debug build (not implemented in this spec yet)
-%global debug_package %{nil}
+#global debug_package %{nil}
# %%{nil} for Stable; -beta for Beta; -dev for Devel
# dash in -beta and -dev is intentional !
@@ -932,7 +932,7 @@ popd
# Core defines are flags that are true for both the browser and headless.
CHROMIUM_CORE_GN_DEFINES=""
-CHROMIUM_CORE_GN_DEFINES+=' is_debug=false'
+CHROMIUM_CORE_GN_DEFINES+=' is_debug=false symbol_level=2'
%ifarch x86_64 aarch64
CHROMIUM_CORE_GN_DEFINES+=' system_libdir="lib64"'
%endif
@@ -960,7 +960,7 @@ CHROMIUM_BROWSER_GN_DEFINES+=' is_component_ffmpeg=true
is_component_build=true'
%else
CHROMIUM_BROWSER_GN_DEFINES+=' is_component_ffmpeg=false
is_component_build=false'
%endif
-CHROMIUM_BROWSER_GN_DEFINES+=' remove_webcore_debug_symbols=true
enable_hangout_services_extension=true'
+CHROMIUM_BROWSER_GN_DEFINES+='
Re: [lldb-dev] [lldb-mi] unable to debug GTK applications
On Tue, 26 Feb 2019 14:52:26 +0100, Eran Ifrah via lldb-dev wrote:
> I am trying a GTK application using lldb-mi, however, the application
> terminates immediately with the error message:
>
> @"15:47:16: Error: Unable to initialize GTK+, is DISPLAY set properly?\r\n"
>
> Running the same using "pure" lldb works as expected.
Using Eclipse the lldb-server environment is empty as nothing sets it.
I tried the attached patch (a copy from StartDebugserverProcess()) which does
fix it for local debugging but it is apparently a wrong patch as it provides
to the application environment from gdbserver, not from Eclipse as it should
by QEnvironmentHexEncoded packets.
As I should do something else is there some known status of the environment
passing? Isn't it some unimplemented Linux-port feature?
Jan
---
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -217,6 +217,9 @@ Status GDBRemoteCommunicationServerLLGS::LaunchProcess() {
m_process_launch_info.SetLaunchInSeparateProcessGroup(true);
m_process_launch_info.GetFlags().Set(eLaunchFlagDebug);
+ // Copy the current environment to the gdbserver instance
+ m_process_launch_info.GetEnvironment() = Host::GetEnvironment();
+
if (should_forward_stdio) {
if (llvm::Error Err = m_process_launch_info.SetUpPtyRedirection())
return Status(std::move(Err));
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Remote debugging a docker process
On Sun, 03 Mar 2019 04:17:42 +0100, Mason Kramer via lldb-dev wrote: > Then, I restricted the acceptable range of > gdbserver ports to just 5001, using the flags suggested in the email. > > lldb-server-4.0 platform --verbose --listen "*:5000" --min-gdbserver-port > 5001 --max-gdbserver-port 5001 There should be 5002 as --max-gdbserver-port is in reality "max+1" value and not "max" value. The options --min-gdbserver-port and --max-gdbserver-port get ignored this way. Submitted: Sanity check --max-gdbserver-port https://reviews.llvm.org/D58962 Replied with a working Docker example: Remote LLDB debugging - Docker container https://stackoverflow.com/a/55004346/2995591 # Add an option 'allow-all-hosts' to permit lldb debugging inside a Docker container > [2] https://reviews.llvm.org/D42845 I also haven't found a need for this new proposed option. Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Unreliable process attach on Linux
On Fri, 04 Jan 2019 17:38:42 +0100, Florian Weimer via lldb-dev wrote: > Run it in a loop like this: > > $ while ./test-attach ; do date; done > > On Linux x86-64 (Fedora 29), with LLDB 7 (lldb-7.0.0-1.fc29.x86_64) and > kernel 4.19.12 (kernel-4.19.12-301.fc29.x86_64), after 100 iterations or > so, attaching to the newly created process fails: > > test-attach: SBTarget::Attach failed: lost connection FYI after 3 runs it still runs fine with your reproducer both with system lldb-devel-7.0.0-1.fc29.x86_64 and COPR lldb-experimental-devel-8.0.0-0.20190102snap0.fc29.x86_64 (=trunk), part running without /usr/lib/debug and part with. Fedora 29 x86_64 + kernel-4.19.10-300.fc29.x86_64 (I haven't investigated the code why it could fail this way.) Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [lit] check-all hanging
On Thu, 03 Jan 2019 23:47:59 +0100, Adrian Prantl via lldb-dev wrote: > > On Jan 3, 2019, at 8:30 AM, Frédéric Riss wrote: > >> I immediately ran it again and saw one new unexpected fail: > >> lldb-Suite :: tools/lldb-mi/syntax/TestMiSyntax.py > > > > Adrian, do we have remaining flakiness in the MI tests? Is this one of the > > GSoc tests? > > That particular test still uses pexpect and needs to be rewritten as a > LIT-based test; so, yes. TestMiSyntax was the only test failing for me with /usr/lib/debug debuginfos installed on Linux and Joel may be running a Linux platform according to some of his mails. I have now checked in a fix which may remove this false FAIL: https://reviews.llvm.org/D55859 symbols.enable-external-lookup=false on all hosts (not just OSX) Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] buildbot master configs [Re: buildbot deployment: gsutil: Anonymous caller does not have storage.objects.create access to lldb_test_traces]
Hello,
I need a testing local buildbot instance to develop a buildbot slave config:
On Thu, 02 Aug 2018 14:47:42 +0200, Pavel Labath via lldb-dev wrote:
> On Thu, 2 Aug 2018 at 13:39, Jan Kratochvil wrote:
> > On Thu, 02 Aug 2018 13:47:25 +0200, Pavel Labath wrote:
> > > *However*, for setting up a new bot, I'd recommend not using this
> > > particular slave factory (getLLDBScriptCommandsFactory) at all,
> > > because it's heavily customized for our use case (*), and very
> > > different from how typical llvm buildbots are set up. You might be
> > > better off setting up a new factory, which just does the typical
> > > checkout+build+(optional) test steps, and avoids all of this mess.
> >
> > OK. For development of these new steps I guess I should run my own buildbot
> > master instance? As otherwise that will be probably several/many commits to
> > zorg repo (+requested buildbot master restarts) and I may screw up something
> > along.
>
> Yes, that would definitely be the best, but last time I tried that, I
> couldn't get my master instance to run, for any approximation of the
> word "run" (which is part of the reason why I haven't done anything
> about this slave factory, even though I really don't like it)..
I have found buildbot versions different than 0.8.5 are incompatibile with
LLVM infrastructure/configs so to run 0.8.5 on Fedora 28 x86_64 I have
backported:
https://people.redhat.com/jkratoch/buildbot-0.8.5-fix.patch
https://people.redhat.com/jkratoch/buildbot-0.8.5-fix2.patch
So I downloaded zorg from LLVM and set it up
[buildbot@host1 ~]$ ls -l lldbmaster
lrwxrwxrwx 1 buildbot buildbot 32 Aug 14 18:55 lldbmaster ->
zorg-git/buildbot/osuosl/master/
[buildbot@host1 ~]$ ls -l lldbmaster/
total 76
-rw-r--r-- 1 buildbot buildbot 878 Aug 14 15:25 buildbot.tac
drwxr-xr-x 2 buildbot buildbot 4096 Aug 14 19:01 config
-rw-r--r-- 1 buildbot buildbot 9552 Aug 14 15:25 master.cfg
drwxr-xr-x 2 buildbot buildbot 4096 Aug 14 15:25 public_html
-rw-r--r-- 1 buildbot buildbot 465 Aug 14 15:25 README.txt
drwxr-xr-x 2 buildbot buildbot 4096 Aug 14 15:25 templates
-rw-r--r-- 1 buildbot buildbot 34088 Aug 14 19:01 twistd.log
-rw--- 1 buildbot buildbot 7 Aug 14 19:01 twistd.pid
lrwxrwxrwx 1 buildbot buildbot28 Aug 14 19:00 zorg ->
/home/buildbot/zorg-git/zorg
with zorg-git directory from https://llvm.org/git/zorg.git patched as attached
but then I still get:
--
$ buildbot start ~/lldbmaster
Following twistd.log until startup finished..
/home/buildbot/.local/lib/python2.7/site-packages/buildbot-latest-py2.7.egg/buildbot/schedulers/base.py:111:
DeprecationWarning: twisted.internet.defer.deferredGenerator was deprecated in
Twisted 15.0.0; please use twisted.internet.defer.inlineCallbacks instead
@defer.deferredGenerator
... ^^^ this looks harmless
2018-08-14 14:35:04+0200 [-] error while parsing config file
2018-08-14 14:35:04+0200 [-] Unhandled Error
Traceback (most recent call last):
File
"/home/buildbot/.local/lib/python2.7/site-packages/buildbot-latest-py2.7.egg/buildbot/master.py",
line 197, in loadTheConfigFile
d = self.loadConfig(f)
File
"/home/buildbot/.local/lib/python2.7/site-packages/buildbot-latest-py2.7.egg/buildbot/master.py",
line 579, in loadConfig
d.addCallback(do_load)
File "/usr/lib64/python2.7/site-packages/twisted/internet/defer.py",
line 317, in addCallback
callbackKeywords=kw)
File "/usr/lib64/python2.7/site-packages/twisted/internet/defer.py",
line 306, in addCallbacks
self._runCallbacks()
--- ---
File "/usr/lib64/python2.7/site-packages/twisted/internet/defer.py",
line 587, in _runCallbacks
current.result = callback(current.result, *args, **kw)
File
"/home/buildbot/.local/lib/python2.7/site-packages/buildbot-latest-py2.7.egg/buildbot/master.py",
line 226, in do_load
exec f in localDict
File "/quad/home/buildbot/lldbmaster/master.cfg", line 104, in
standard_categories)
File "/quad/home/buildbot/lldbmaster/config/status.py", line 31, in
get_status_targets
default_email = config.options.get('Master Options',
'default_email')
File "/usr/lib64/python2.7/ConfigParser.py", line 330, in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'Master Options'
--
I have found last zorg files containing '[Master Options]' have been removed by:
https://reviews.llvm.org/D30503
commit a4a7c00a15e94bf2a26ec209d27e6ece5c20a16b
git-svn-id: https://llvm.org/svn/llvm-project/zorg/trunk@296756
91177308-0d34-0410-b5e6-96231b3b80d8
[lldb-dev] buildbot deployment: gsutil: Anonymous caller does not have storage.objects.create access to lldb_test_traces
Hello, trying a test deployment of a buildbot but I do not see how to deploy the final: upload test traces './uploadTestTrace.sh 43 ...' failed ( 10 secs ) http://lab.llvm.org:8014/builders/lldb-x86_64-fedora-28-cmake/builds/43/steps/upload%20test%20traces/logs/stdio I was following this guide but various steps are missing there, I will submit them after I get it running. https://llvm.org/docs/HowToAddABuilder.html I have done for the last step: wget https://storage.googleapis.com/pub/gsutil.tar.gz ./setup.py install --user But maybe it wants also: gsutil config But I have no idea which Google Cloud Platform Project ID should I enter, additionally it even wants from me to pay for Google Cloud Platform. Thanks, Jan Kratochvil ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm
On Mon, 18 Jun 2018 18:57:07 +0200, Greg Clayton wrote: > I do agree. Probably no one else will want/need this in DWARF except us as > I don't believe anyone else is re-creating compiler types with DWARF. GDB-GCC try to copy the LLDB approach: https://sourceware.org/gdb/wiki/GCCCompileAndExecute Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Handling DWARF "units"
On Fri, 13 Apr 2018 21:06:03 +0200, paul.robin...@sony.com wrote: > Also I understand Jan Kratochvil is working on making Partial Units > a thing in the LLDB DWARF parser, as part of his DWZ work, Yes, with some integration discussions in the threads: [Lldb-commits] [PATCH] D45170: Cleanup DWARFCompileUnit and DWARFUnit in preparation for adding DWARFTypeUnit https://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20180409/040193.html [Lldb-commits] [PATCH] D32167: Add support for type units (.debug_types) to LLDB in a way that is compatible with DWARF 5 https://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20180409/040199.html > The main reason I'm sending up this particular flare right now is that I'm > about to head off to EuroLLVM and if other interested parties will be there, I am sorry I won't be at this EuroLLVM. Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Command history line editing
On Sun, 04 Mar 2018 21:03:26 +0100, William Schmidt via lldb-dev wrote: > lldb deserves an editing mode functionally equivalent to what bash offers. > And since bash is open-source, it should just be a matter of grabbing the > bash source that implements command line editing and going from there. It is because lldb uses libedit while bash (and gdb) use readline. I guess it has licensing reasons as readline is GPL (not LGPL) and Apple seems to avoid GPL the family of licenses. IANAL but I think an alternative linking with readline while keeping the libedit compatibility still in place would not taint LLDB by the GPL license. And then OSes (such as Linux or for OSX is it Homebrew?) already using GPL software could link LLDB with readline. Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Adding DWARF5 accelerator table support to llvm
On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote: > so I'm writing this email to see if there's anyone > else interested in this topic, and to try to synchronize our efforts. I am sure interested in DWARF-5 .debug_names. I wrote its producer+consumer for GDB (but not producing/using DW_IDX_DIE_offset as GDB cannot use it). > 1. add .debug_names support to llvm-dwarfdump via the DebugInfo > library (to enable testing of the table generation) FYI FSF binutils readelf can read .debug_names already for some possible format cross-check (to prevent multiple incompatible implementations). > 2. add .debug_names generation support (not enabled by default) + > I also have a very basic implementation of (2), but this is still quite far > from being upstreamable. Originally I expected I will reuse the GDB .debug_names producer for LLVM: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=437afbb81e3a04cbd933fc534a50c686eaa63b19 https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=8af5c486ea6153bb84b9257def4e5faa4bc72421 But I see you were faster. Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] solved: Unifying ctor+Clear() inits into in-class initializers?
On Sun, 19 Nov 2017 15:58:02 +0100, Jan Kratochvil via lldb-dev wrote:
> https://reviews.llvm.org/D40212
...
> Is it OK to just use in-class member variable initializers and:
> void Clear() {
> this->~ClassName();
> new (this) ClassName();
> }
> ?
FYI Greg Clayton in the review above decided this is not good and it will be
better to avoid Clear() completely.
Jan Kratochvil
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Unifying ctor+Clear() inits into in-class initializers?
Hi,
https://reviews.llvm.org/D40212
At least DWARFCompileUnit and I see even for example MachVMRegion duplicate
intialization of fields in both their constructor and Clear(). Moreover the
initialization is in different place than declaration of the member variable.
Is it OK to just use in-class member variable initializers and:
void Clear() {
this->~ClassName();
new (this) ClassName();
}
?
Pavel Labath otherwise suggests to just call Clear() from the constructor.
Still then I find the code could be more readable with in-class members
initializers - moreover during further refactorizations+extensions.
Thanks,
Jan Kratochvil
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Linking the lldb C++API/library with other projects
On Tue, 29 Aug 2017 21:05:32 +0200, meister via lldb-dev wrote: > Common Lisp is a different kind of language - it’s never supposed to seg > fault. :-) > > It’s a dynamic language that I am compiling to llvm-ir and using to call and > drive C++ libraries. > The integrated debugger takes over when an error is signaled So "error is signaled" is like an assert()? assert() generates SIGABRT so that system crash reporter will catch it, backtrace it, bugreport it etc. Or a debugger will catch it the same way if developer has run it. Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Linking the lldb C++API/library with other projects
On Tue, 29 Aug 2017 20:17:57 +0200, meister via lldb-dev wrote: > (i) My program detects an error and enters into its debugger. > (ii) It forks a debugging process and that interacts with the user who uses > it to debug the main process. > (iii) The debugger process shuts down and the main process continues. For catching runtime errors on Linux you should just SEGV and system crash reporter will catch it, backtrace it, bugreport it etc. At least ABRT in Fedora/RHEL case, other distros have some similar tools for that. And developers should run the program under debugger in the first place. Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] RFC for DWZ = DW_TAG_imported_unit + DWARF-5 supplementary files
On Wed, 23 Aug 2017 23:55:00 +0200, Greg Clayton wrote: > > On Aug 23, 2017, at 2:06 PM, Jan Kratochvil via lldb-dev > > <lldb-dev@lists.llvm.org> wrote: > > Currently it always has to as on non-OSX platforms it is using > > DWARFCompileUnit::Index(). But as I plan to implement DWARF-5 .debug_names > > index (like __apple_* index) maybe LLDB then no longer needs to populate > > m_die_array and so just expanding all DW_TAG_partial_unit into a single > > m_die_array for each DW_TAG_compile_unit is fine? > > So I glossed over the documentation and I gathered that DWARF type info > might be stored in other DWARF files and references from the current file. Yes. Arbitrary DIEs, not just type-defining DIEs. DW_TAG_imported_unit can happen anywhere according to the DWARF standard but for the DWZ/Fedora case it is a bit simpler one can limit the support for only DW_TAG_imported_unit with parent of DW_TAG_compile_unit (or DW_TAG_partial_unit for nested imports). DWZ ever uses DW_TAG_imported_unit only at the CU/PU top level. > SymbolFileDWARFDebugMap is an example of how we do things on MacOS. We have > one clang::ASTContext in the SymbolFileDWARFDebugMap, and multiple external > .o files (where each ins a SymbolFileDWARF instance) that contain unlinked > DWARF. Each SymbolFileDWARF instance will have: > > void SymbolFileDWARF::SetDebugMapModule(const lldb::ModuleSP _sp); > > called to indicate it is actually part of the SymbolFileDWARFDebugMap. > Then there are functions that check the debug map file and return the > UniqueDWARFASTTypeMap or the TypeSystem from the SymbolFileDWARFDebugMap if > we have one: Therefore IIUC you make a single context for all types from a compiled program? Primitive (non-class) types can be different across CUs: CU1: typedef int foo_t; CU2: typedef long foo_t; I have a problem that one DW_TAG_partial_unit can be included by multiple DW_TAG_compile_unit. Therefore DWARFCompileUnit for DW_TAG_partial_unit itself cannot map itself by SymbolFileDWARFDebugMap to its parent DWARFCompileUnit for DW_TAG_compile_unit (as it has multiple parents). I expect you cannot link a single MacOS object file into two diferent programs/libraries which are debugged at once by LLDB. > One other idea is to keep all DWARF files separate and stand alone. Your > main DWARF file with one or more DW_TAG_imported_unit and all > DW_TAG_imported_unit referenced files, each as its own SymbolFileDWARF. Any > reference to a DW_FORM_ref_alt would turn into a forward declaration in the > current SymbolFileDWARF, so the ASTContext in each SymbolFileDWARF wouldn't > know anything about the types, Is it applicable even if DW_TAG_imported_unit points to DW_TAG_partial_unit's containing DW_TAG_variable, DW_TAG_subprogram and arbitrary other DIEs, not just types? > The other approach I might suggest is to write a DWARF linker, maybe using > LLVM's DWARF classes (see llvm-dsymutil sources) that takes the top level > DWARF and all DW_TAG_imported_unit files and combines them all back into one > large DWARF file. That would defeat the advantage of DWZ-optimized debug info files. DWZ reduces their size by approx. 30%. If the relinking was made on-demand then it defeats the LLDB performance advantage over GDB - GDB can already read DWZ natively (GDB does duplicates the internal representation when reading DWZ CUs/PUs). In such case I could already code such reconstruction of non-DWZ debug info when reading m_die_array - but that also seems needlessly slow to me. DWZ should bring even performance advantage of parsing the DWZ common file (=imported file) only once. > One other idea is to let each DWARF file be separate, and when you need > a type from a DW_TAG_imported_unit you log that file as stand alone and copy > the type from its clang::ASTContext into the main SymbolFileDWARF's AST > context. We copy types all the time in expressions as each on has its own > AST context. Does this work even for non-type DIEs? > So there are many solutions. I would vote for linking the DWARF into > a single file much like we do with llvm-dsymutil on Mac, but that really > depends if the type uniquing is desired within a single DWARF file and not > across many shared libraries that all reference common DW_TAG_imported_unit > files. I agree the DWZ optimization does primarily what -fdebug-types-section does. I do not see why to really do relinking files on disk, debugger should not need that to read the debug info. I do not fully understand why you do the llvm-dsymutil relinking when you already have SymbolFileDWARFDebugMap in LLDB. But I do not know OSX/Mac. Thanks, Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface
On Sat, 29 Jul 2017 21:59:03 +0200, ylluminate via lldb-dev wrote: > And one thread seems to indicate that if if we could "convince LLDB > developers to provide > a decent implementation of the GDB/MI protocol, That is an oxymoron. MI protocol was designed to minimize the amount of data transferred between gdb/lldb and a front end. But this communication isn't anything expensive as the debugger always runs on the same host as the frontend anyway (gdb/lldb<->gdbserver link is for remote debugging). Unfortunately complexity of the GDB/MI protocol from this misoptimization leads to many bugs on both sides of the implementation, for GDB: https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=SUSPENDED_status=WAITING_status=REOPENED=mi_id=37310=gdb_format=advanced 101 bugs found. The MI protocol in use does not conform to its spec as there is a bug-to-bug compatibility instead such as: https://sourceware.org/ml/gdb-patches/2008-11/msg00275.html There still also isn't any reasonable MI library to be used by a front end. I find the LLDB API to be a better choice to be used by the frontend/emacs (I have only little but great experience with the LLDB API). Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] DWZ support?
Hello, at least Fedora Linux distribution uses DWZ to reduce DWARF debug info size: https://fedoraproject.org/wiki/Features/DwarfCompressor It is DWARF optimization - not really a compression. One can find it by DW_TAG_partial_unit/DW_TAG_imported_unit: <0>: Abbrev Number: 103 (DW_TAG_partial_unit) DW_AT_stmt_list : 0x0 <10> DW_AT_comp_dir: (alt indirect string, offset: 0xe61c) <1><14>: Abbrev Number: 45 (DW_TAG_imported_unit) <15> DW_AT_import : ... LLDB (incl. trunk) does not support it and it even crashes on DWZed files. Is anyone working on this support? To prevent possible work duplication. I have found only this commit but that is not really for LLDB: https://reviews.llvm.org/rL237721 Jan Kratochvil ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
