GDB 10.1 | Hacker News Reader

GDB 10.1

lists.gnu.org

155 pointslelf29 comments

> * Support for debuginfod, an HTTP server for distributing ELF/DWARF debugging information as well as source code.

This is huge! Microsoft's symbol servers have long made it easier to deal with PDBs. This will finally help with the annoyingness of -debuginfo and -debug Linux packages.

Edit: Background on debuginfod: https://developers.redhat.com/blog/2019/10/14/introducing-de...

Is there any other implementation of the same API, but not GPLv3? I'm thinking from LLVM or similar?

I’m a huge proponent of MIT/BSD but I wouldn’t blink twice at deploying this. The code running on your end doesn’t need to be GPL to communicate with a GPL’d server over the network.

I agree. Explaining that to lawyers is a bit tougher.

In the early 2000s many lawyers were conservative about these things. These days many lawyers working with technology licensing in businesses are very much up to date. Don't be afraid to keep open lines of communication.

If the lawyers need this to be explained to them, they're not very good at their job.

Are you hoping to modify it and refuse to contribute your changes back to the community?

If not, the GPL will not affect you. If so, does that not feel like mooching off the community?

Aren't you assuming the worst here? Why so strident?

Maybe his/her employer does not allow gpl software...

> Maybe his/her employer does not allow gpl software...

Then they aren't using GCC (or Linux) in the first place.

Then replace "you" with "your employer". The point still applies.

I don't personally care it's GPLv3. I know given the way I'd use it there's no actual risk, or if I did modify it there'd be no reason not to contribute back. I do care about getting fired for violating company policy.

GPLv2 can be approved fairly easily. GPLv3 is a much tougher sell. For example, GCC is fine because there's really no alternative (or there wasn't before clang had full compatibility).

Why would GPL 2 vs 3 matter? Is the company doing hardware appliances or something?

Its probably the patent grant that has their lawyers squeamish.

Many corporations accept using GPLv2 code to some extent, while GPLv3 is just a red flag. Tivoization is one problem. If you have GPLv3 in your (embedded) product, you must provide tools to the customer to reflash it. Many corporations don't want that, and in cases where type appovals are required it might be illegal. Think of a car owner reprogramming the engine control unit or the brakes.

That's probably all not very applicable to gdb, but corporate policies might not allow such a nuanced perspective.

The ECU would definitely constitute mere aggregation with respect to e.g. the in-car entertainment system.

Also, reprogramming the ECU is already possible, and it's also not illegal to do it. It may very well void your warranty and it might be illegal to use the car on public roads after having reprogrammed the ECU, but neither of those two things are incompatible with the GPL.

> and it might be illegal to use the car on public roads after having reprogrammed the ECU, but neither of those two things are incompatible with the GPL.

Actually I think that would constitute a GPL violation on the part of the government (enforcing additional restrictions on the use of the software), although the government is generally not the one distributing the code (and also good luck holding them accountable even if they were).

You can't violate the GPL if you aren't a party to the license (i.e. if you aren't copying copyrighted works). I don't know if it's a GPLv3 violation to distribute software in hardware that the user can technically buy not legally modify. The license just says this:

> The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

Right, that probably should have been:

> > that would constitute a GPL violation on the part of the government [if the government were the ones distributing it] [...]

It would be nice to close this loophole (prevent or at least disincentivise the goverment from making such laws), but it's not clear how that could be accomplished.

I won't matter even if modifications are made so long is it isn't distributed outside the company. Corporate personhood means your coworkers are all part of a single legal entity. GPL cannot apply.

This is in the works for LLDB.

https://reviews.llvm.org/D75750

The feature itself is multi-platform and is not original to GDB.

https://sourceware.org/elfutils/Debuginfod.html

Those packages are separate so you don't have a bunch of debug info laying around that a very small percentage of the user base will use. Hosting this on the web is cute but not as convenient as just a package that can easily be distributed via sneakernet if need be.

Debian and Ubuntu and them could still host the package in apt, but it's nice that I could download them last-second right when I'm in GDB without fussing with apt.

The point is that you can get them on-demand and it doesn't require root privileges. As the Red Hat article notes:

> For example, your distro might package debuginfo and source files separately from the executable you’re trying to debug and you may lack the permissions to install these packages. Or, perhaps you’re debugging within a container that was not built with these resources, or maybe you simply don’t want these files taking up space on your machine.

Also, FYI, sneakernet is the wrong term for what you meant. Sneakernet is the transfer of files over something other than a computer network (i.e. walking a USB drive to a friend wearing sneakers).

It's not noted in the NEWS, but the NetBSD Project introduced almost 100 commits in the binutils-gdb repository this year, improving the hardware support, reaching feature parity with generic features, adding support for gdbserver (the first and so far the only one out of BSDs).

There are reports of this work on blog.netbsd.org

If you think something is NEWS-worthy, just propose a patch for it!

I saw Ada as the first language, and that brought back fond memories of optimizing compiler design I did for the language a long long time ago...

Just want to give a shout out to the people who have been improving GDB's Python API over the years (I think it first appeared about 10 years ago). It seems like a lot of it is due to Tom Tromey? [1]

This is a super useful feature that I just used. I have a DSL for algebraic data types in C++ called ASDL [2], and I wrote a very small Python plugin that pretty prints the types.

Basically it automates the process of looking at the runtime type tag, and downcasting to the right variant, so you can see all the fields in the debugger. (Variants are naturally modeled with inheritance, and you still have type safety)

This makes debugging the code way easier. I basically enhanced C++'s type system and now the debugger also understands it!

It works on the command line and the Eclipse GUI. Although I should get around to requesting an open source license for CLion, because I think it is significantly more polished.

-----

GDB is very old, and has sort of a bad reputation for usability, but it's getting better after all these years! This scripting power can make up for the usability in some cases (and maybe CLion will give the best of both worlds)

https://lobste.rs/s/h7f6qk/what_debugging_technique_did_it_t...

[1] https://tromey.com/blog/?m=201809

https://tromey.com/blog/?p=927

[2] What is Zephyr ASDL? https://www.oilshell.org/blog/2016/12/11.html

ASDL is mentioned in the post about Ungrammar, on the front page now: https://news.ycombinator.com/item?id=24878098

> Multi-target debugging support

This is great! I really needed this multiple times over the years. Always wanted to compare some data between 2 executions of the same applications with 2 different inputs or 2 revisions of an application. This should really help with triangulation of regressions etc. automatically using a single script within gdb!

GDB has had that in the form of Multi-process debugging for a while. Multi-target I believe extends this different remote stubs and architectures, such as debugging both an x86 and x86-64 process. Besides that I agree it's really useful on the occasions that you need it to hunt down some non-determinism or what not.

Reply on news.ycombinator.com