Re: drkonqi's many debuggers
On Monday, 28 August 2023 21:33:25 PDT Nate Graham wrote: > On 8/28/23 22:25, Thiago Macieira wrote: > > 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. > > DrKonqi itself could declare a required build dependency on lldb, and > then we would know it's present on the system. Distros that don't > package it would then have to omit DrKonqi, or start packaging it. Build dependencies don't necessarily translate to runtime dependencies. What you're asking for is package management, something we don't control. Yes, we could convince all packagers to add it, but a) that's not a sure-fire guarantee b) do we even want to? Do we want to make it so every user who installs Plasma Workspace must have a debugger? No, debuggers are optional. Then there's my argument about libdebuginfo integration. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: drkonqi's many debuggers
On 8/28/23 22:25, Thiago Macieira wrote: 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. DrKonqi itself could declare a required build dependency on lldb, and then we would know it's present on the system. Distros that don't package it would then have to omit DrKonqi, or start packaging it. Nate
Re: drkonqi's many debuggers
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. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering .
Re: drkonqi's many debuggers
On Tue, Aug 29, 2023 at 5:23 AM Thiago Macieira wrote: > > On Monday, 28 August 2023 12:59:01 PDT Adriaan de Groot wrote: > > (puts on FreeBSD hat) On the non-GNU side of the world, lldb is the thing > > that is "installed anyway" and gdb takes extra effort. Though I don't know > > if the lldb integration works -- I have both installed, and I don't know if > > I ever bother to interact with DrKonqi (sorry). > > True, but the majority of our user base is still Linux, so if we had to choose > only one, it would have to be gdb. 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. HS
Re: drkonqi's many debuggers
On Monday, 28 August 2023 12:59:01 PDT Adriaan de Groot wrote: > (puts on FreeBSD hat) On the non-GNU side of the world, lldb is the thing > that is "installed anyway" and gdb takes extra effort. Though I don't know > if the lldb integration works -- I have both installed, and I don't know if > I ever bother to interact with DrKonqi (sorry). True, but the majority of our user base is still Linux, so if we had to choose only one, it would have to be gdb. That's probably why we need to have both gdb and lldb supported. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: drkonqi's many debuggers
On Monday, 28 August 2023 17:23:00 CEST Harald Sitter wrote: > I am wondering: does anyone actually use anything besides the default > gdb debugger? We have a lot of code just for supporting multiple > debuggers and I am wondering if we couldn't just focus on one debugger > and get less code with a better experience (both in writing and > reading it). (puts on FreeBSD hat) On the non-GNU side of the world, lldb is the thing that is "installed anyway" and gdb takes extra effort. Though I don't know if the lldb integration works -- I have both installed, and I don't know if I ever bother to interact with DrKonqi (sorry). [ade] signature.asc Description: This is a digitally signed message part.
Re: drkonqi's many debuggers
On Monday, 28 August 2023 08:23:00 PDT Harald Sitter wrote: > On a related note: does anyone have opinions on using lldb instead of > gdb? This contradicts your earlier point of: > I am wondering if we couldn't just focus on one debugger > and get less code with a better experience (both in writing and > reading it). If you want *one* debugger, then it has to be GDB on Linux, because it's the one that most people will have installed. $ lldb --version zsh: command not found: lldb -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
drkonqi's many debuggers
I am wondering: does anyone actually use anything besides the default gdb debugger? We have a lot of code just for supporting multiple debuggers and I am wondering if we couldn't just focus on one debugger and get less code with a better experience (both in writing and reading it). On a related note: does anyone have opinions on using lldb instead of gdb? It seems much faster to me and should be just as scriptable as gdb from a quick glance. The trace format would change though, so that's a challenge. OTOH texty traces are a thing of the past with sentry anyway. HS
