Author just did a podcast about Uscope a few minutes ago, where they mention this HN post:
Mentioned at : https://youtu.be/stWBTv6grBc?t=456
Show HN: Uscope, a new Linux debugger written from scratch
61–70 of 133 posts
Re: Show HN: Uscope, a new Linux debugger written from scratch
#62> The available Linux debuggers are gdb and lldb. They both suck. They crash all the time, don't understand the data types I care about, and they don't make the data I need available at my fingertips as quickly as possible. quote from https://calabro.io/uscope Of course gdb, lldb have their problems (e.g. smashing tui with app output, what can be easily fixed, or very very very very long tab-tab completion, and crash…
Which visual studio are you using?
It’s been a number of years since I’ve used it but Visual Studio PRO could do all these things - at least as long as I was using it (since visual c++ 5).
VS Code on the other hand is no where near as featured or powerful.
Re: Show HN: Uscope, a new Linux debugger written from scratch
#63It's not clear to me why we'd need a new debugger instead of GDB enhancements. GDB has an extensible, modern C++ codebase with literal decades of hard earned knowledge baked into it. How are we better off rewriting it, especially if the rewrite isn't memory safe?
GDB is awful and a replacement is sorely needed. It's buggy and slow and feature poor and has a terrible UI and a terrible API which makes all the frontends terrible in turn. I haven't looked at its code but I'm betting it's terrible too.
> a terrible API which makes all the frontends terrible in turn
I don't know the details. But nowadays gdb supports DAP, as any other debugger: https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/D...
Are you talking about this, or the old https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/G... ?
Re: Show HN: Uscope, a new Linux debugger written from scratch
#64Earlier quoted context omitted.
I haven't tried UScope yet (I shall), but I don't agree with you about GDB. I don't find it especially buggy unless doing niche things like non-stop debugging -- I guess you may well have a different experience though. I think the UI is much maligned unfairly. It has a few quirks, but ever used git? For the most part it's fairly consistent and well thought through. By terrible API you mean the Python? I admit it can…
> What features do you most miss? one time I wanted to write generic printers. E.g. printer of any type which support C++ iterators. But gdb can't call C++ functions from python api (excepting weird hacks like evaluating `print c.begin()` and catching it output). Although this is not very useful because most of types we use changes very rarely, that's why writing printers is only matter of time. Another feature is br…
> one time I wanted to write generic printers. E.g. printer of any type which support C++ iterators.
How would that work for types where the required functions are not instantiated, or not instantiated as a standalone function? Most iterators' operator++ are inlined and probably never instantiated as a distinct function.
Re: Show HN: Uscope, a new Linux debugger written from scratch
#65> The available Linux debuggers are gdb and lldb. They both suck. They crash all the time, don't understand the data types I care about, and they don't make the data I need available at my fingertips as quickly as possible. quote from https://calabro.io/uscope Of course gdb, lldb have their problems (e.g. smashing tui with app output, what can be easily fixed, or very very very very long tab-tab completion, and crash…
Which visual studio are you using? It’s been a number of years since I’ve used it but Visual Studio PRO could do all these things - at least as long as I was using it (since visual c++ 5). VS Code on the other hand is no where near as featured or powerful.
I use VS2022 Enterprise
If you know solutions, I will be very thankful for any info.
P.S.
Note, though I meet all of this problems, probably I don't spent enough time to find a solution (maybe tried first links at google and so on). E.g. tried `strcmp` for breakpoints, tried to write .natstepfilter.
So, if VS really can do all of this, I'm sorry for my hurry.
Re: Show HN: Uscope, a new Linux debugger written from scratch
#66> Build as a library so other people can build other interesting things as well I LOVE this! I firmly believe so much tech has gone to shit because things are no longer hackable. We say "move fast and break things" but we try so hard to prevent that that when we do break things we just create bigger messes and debt, so no one cleans it up. It seems slower to write hackable code but that's in the moment. In the long r…
Is gdb another thing like gcc where the un-hackability and un-extendability was a deliberate choice by rms to ensure nobody would ever build proprietary toolchains on top of it?
gdb is a bit old and my comment is really more about building things in general.
You should always make things hackable, not just for others, but for you. One truth to coding is that the final thing will never end up where you think it will. So if you don't make your code flexible (i.e. hackable) then you're going to keep breaking it while fixing it. Things will continue to be patches and quick fixes. Nothing is more permanent than a temporary fix that works.
Truthfully, this is part of the unix philosophy. Make your programs small and integratable. The strategy is not to be finished, because there is no end, the strategy is to be adaptable, because there is no end.
Re: Show HN: Uscope, a new Linux debugger written from scratch
#67> The available Linux debuggers are gdb and lldb. They both suck. They crash all the time, don't understand the data types I care about, and they don't make the data I need available at my fingertips as quickly as possible. quote from https://calabro.io/uscope Of course gdb, lldb have their problems (e.g. smashing tui with app output, what can be easily fixed, or very very very very long tab-tab completion, and crash…
rr should work on any remotely modern Intel system, and generally on AMD's Zen CPUs too. Unless you're in a virtualized environment (some of which are supported) or a more esoteric architecture rr probably works on your silicon.
I have AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx (8) @ 2.100GHz.
As I remember - it is should work according to documentation, but I couldn't launch it. Probably I'm not spend enough time to solve errors
Re: Show HN: Uscope, a new Linux debugger written from scratch
#68Earlier quoted context omitted.
> What features do you most miss? one time I wanted to write generic printers. E.g. printer of any type which support C++ iterators. But gdb can't call C++ functions from python api (excepting weird hacks like evaluating `print c.begin()` and catching it output). Although this is not very useful because most of types we use changes very rarely, that's why writing printers is only matter of time. Another feature is br…
> one time I wanted to write generic printers. E.g. printer of any type which support C++ iterators. How would that work for types where the required functions are not instantiated, or not instantiated as a standalone function? Most iterators' operator++ are inlined and probably never instantiated as a distinct function.
> How would that work for types where the required functions are not instantiated
Obviously, it will not. But why not to try?)
> Most iterators' operator++ are inlined
Sure, it's sad.
But I'm still think that such feature - calling C++ functions from Python API - can be useful.
Re: Show HN: Uscope, a new Linux debugger written from scratch
#69Earlier quoted context omitted.
> What features do you most miss? one time I wanted to write generic printers. E.g. printer of any type which support C++ iterators. But gdb can't call C++ functions from python api (excepting weird hacks like evaluating `print c.begin()` and catching it output). Although this is not very useful because most of types we use changes very rarely, that's why writing printers is only matter of time. Another feature is br…
> excepting weird hacks like evaluating `print c.begin()` and catching it output) Why do you consider that a weird hack instead of legitimate programming technique?
If this is not weird hack, why gdb provide api for getting C++ variables values instead of using this "legitimate programming technique"?
Re: Show HN: Uscope, a new Linux debugger written from scratch
#70Everyone here seems to thing GDB is awful. It's been a while for me but I remember using front-ends like Eclipse's CDT or similar and didn't find that experience so bad. Do most people use GDB straight-up? I haven't done that in probably 15 years although it's nice to have a lightweight command line on small embedded systems.
> Everyone here seems to thing GDB is awful. It's been a while for me but I remember using front-ends like Eclipse's CDT or similar and didn't find that experience so bad. Do most people use GDB straight-up? I haven't done that in probably 15 years although it's nice to have a lightweight command line on small embedded systems.
the issue is not with gdb's UX - you can build as many cool UI / UX on top of it as you want. The problem is that gdb will sometimes take 5 minutes to start debugging (and that's without debuginfod), straight up crash, be unable to resolve obvious symbols etc. which are all back-end bugs. For me developing a medium-sized C++ app, it's really hell to use and usually printf debugging is MUCH faster in the sense that I have the time to find and fix my problem through an iterative recompile cycle sometimes before gdb has even finished parsing my binary