[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: drkonqi's many debuggers
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2023-08-29 8:58:43
Message-ID: CA+XidOGE5Vp+na+uC4X5i2y-w4RGdNV06wt4EpHc9mMdptq7+Q () mail ! gmail ! com
[Download RAW message or body]

On Tue, Aug 29, 2023 at 4:25 PM Thiago Macieira <thiago@kde.org> wrote:

> On Monday, 28 August 2023 20:30:36 PDT Harald Sitter wrote:
> > I am not quite following. We can depend on any debugger we want,
> > surely? I mean, there are practical implications to consider for sure,
> > but gdb being the dominant debugger on Linux doesn't prevent us from
> > depending on lldb instead.
>
> It does because it might be missing in the system far more often than gdb.
> We'd get more backtraces and therefore more data if we focused on gdb
>
> Another point is that Linux distributions have been shipping gdb with
> debuginfod support for a year or two. lldb support for it is still pending:
> https://github.com/llvm/llvm-project/issues/52732
>
> Therefore, I repeat: if there's room for only one, it's gdb.
>
> If we do support both, then on Linux gdb must be used in preference.
>

As an additional note here, my preference would also be for gdb to be used,
if only because it is more reliable and dependable.

Currently we have special code in the CI tooling to ensure that stray lldb
processes left behind by unit tests on our FreeBSD CI workers are all
killed off.
Otherwise they sit there eating up an entire CPU core at 100% utilisation
until an admin logs in and kills them off.

Cheers,
Ben


> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel DCAI Cloud Engineering
> .
>
>
>

[Attachment #3 (text/html)]

<div dir="ltr"><div dir="ltr">On Tue, Aug 29, 2023 at 4:25 PM Thiago Macieira \
&lt;<a href="mailto:thiago@kde.org">thiago@kde.org</a>&gt; wrote:<br></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Monday, 28 August \
2023 20:30:36 PDT Harald Sitter wrote:<br> &gt; I am not quite following. We can \
depend on any debugger we want,<br> &gt; surely? I mean, there are practical \
implications to consider for sure,<br> &gt; but gdb being the dominant debugger on \
Linux doesn&#39;t prevent us from<br> &gt; depending on lldb instead.<br>
<br>
It does because it might be missing in the system far more often than gdb. <br>
We&#39;d get more backtraces and therefore more data if we focused on gdb<br>
<br>
Another point is that Linux distributions have been shipping gdb with <br>
debuginfod support for a year or two. lldb support for it is still pending:<br>
<a href="https://github.com/llvm/llvm-project/issues/52732" rel="noreferrer" \
target="_blank">https://github.com/llvm/llvm-project/issues/52732</a><br> <br>
Therefore, I repeat: if there&#39;s room for only one, it&#39;s gdb.<br>
<br>
If we do support both, then on Linux gdb must be used in \
preference.<br></blockquote><div><br></div><div>As an additional note here, my \
preference would also be for gdb to be used, if only because it is more reliable and \
dependable.</div><div><br></div><div>Currently we have special code in the CI tooling \
to ensure that stray lldb processes left behind by unit tests on our FreeBSD CI \
workers are all killed off.</div><div>Otherwise they sit there eating up an entire \
CPU core at 100% utilisation until an admin logs in and kills them \
off.</div><div><br></div><div>Cheers,</div><div>Ben</div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
-- <br>
Thiago Macieira - thiago (AT) <a href="http://macieira.info" rel="noreferrer" \
target="_blank">macieira.info</a> - thiago (AT) <a href="http://kde.org" \
rel="noreferrer" target="_blank">kde.org</a><br>  Software Architect - Intel DCAI \
                Cloud Engineering<br>
.<br>
<br>
<br>
</blockquote></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]