Live data from Hacker News

GDB 10.1

lists.gnu.org

11–20 of 31 posts

Re: GDB 10.1

#11

> * 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...

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.

Re: GDB 10.1

#12
post #4

Earlier quoted context omitted.

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

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?

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).

Re: GDB 10.1

#13
post #4

Earlier quoted context omitted.

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.

Re: GDB 10.1

#14

> * 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...

[deleted]

Re: GDB 10.1

#15
post #4

> * 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?

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

Re: GDB 10.1

#16
post #7

> 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.

Re: GDB 10.1

#17
post #12

Earlier quoted context omitted.

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?

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?

Re: GDB 10.1

#18
post #12

Earlier quoted context omitted.

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.

Re: GDB 10.1

#19
post #12

Earlier quoted context omitted.

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?

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.

Re: GDB 10.1

#20
post #19

Earlier quoted context omitted.

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

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 ve…

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.

Post reply on HN