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_p
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 transfer
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_p
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
> > wrote:
> > Currently it always has to as on non-OSX platforms it is using
> > DWARFCompileUnit::Index(). But as I plan to implement DWARF-5 .deb
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
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
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
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();
> }
>
On Mon, 27 Nov 2017 21:33:04 +0100, Christopher Book via lldb-dev wrote:
> Thoughts?
Not sure if it is applicable in this case but GDB has this feature:
https://sourceware.org/gdb/onlinedocs/gdb/Server.html#Running-gdbserver
(gdb) target remote | ssh -T hostname gdbserver - hello
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/
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.
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
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/GCCCompileAndE
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 follow
On Thu, 02 Aug 2018 13:47:25 +0200, Pavel Labath wrote:
> However, I strongly suspect that you do not want this,
Right.
> *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
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 u
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
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
> s
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
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 "p
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
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
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 x8
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 monorep
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 Haswe
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.
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 STA
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,
> et
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:: th
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 a
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
M
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
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
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
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)
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 suffe
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:
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
38 matches
Mail list logo
