parallel linking still wanted

Posted Feb 4, 2025 20:19 UTC (Tue) by ringerc (subscriber, #3071)
In reply to: parallel linking still wanted by epa
Parent article: GNU Binutils 2.44 Released

IIRC MS Visual Studio's compiler toolchain with msbuild has been doing this for about a decade.

It's a weird mix of a pleasure to use and an absolute horror when I do Windows work. The VS debugger is so good that I've ported C++ codebases to Windows largely so I can use the debugger.

parallel linking still wanted

Posted Feb 4, 2025 21:22 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (6 responses)

Heh. And here I set up entire sanitizer build chains to repro problems on Linux so that I can even get a debugger to give me the time of day. I'm sure there's some way to get it to do so, but attaching to a program without debug info has always been a pain.

parallel linking still wanted

Posted Feb 4, 2025 23:16 UTC (Tue) by ringerc (subscriber, #3071) [Link] (5 responses)

Yep, I've been known to use Linux for `valgrind` and Windows for VC++ debugger on the same project, for the same problem.

At least it isn't golang, where "debugging, who needs that?" seems to be the norm and things like external debuginfo that have been the norm for C and C++ projects for 15 years are just Not A Thing.

parallel linking still wanted

Posted Feb 4, 2025 23:49 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> At least it isn't golang, where "debugging, who needs that?"

Erm... Whut? Golang unconditionally embeds the debugging info, so it's trivially easy to attach with a debugger.

The debugger itself is missing some niceties, like custom type rendering, but it's not too bad.

parallel linking still wanted

Posted Feb 5, 2025 2:52 UTC (Wed) by ringerc (subscriber, #3071) [Link] (3 responses)

Quite right - I was unclear.

What I was getting at is that many projects strip debug info from their builds with:

go build -ldflags "-s -w"

e.g. the Kubernetes project.

As far as I can tell from when I last checked, there is no well supported, portable means of extracting the stripped debug info into a separate archive.

So if a project wants to produce compact release builds, they have no sensible way to publish separate debuginfo - e.g. to a debuginfod and MS symbol server or a simple archive server.

parallel linking still wanted

Posted Feb 5, 2025 3:31 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Oh yeah. K8s is a project that should stop doing that.

There are workarounds: https://github.com/golang/go/issues/51692

parallel linking still wanted

Posted Feb 5, 2025 3:54 UTC (Wed) by ringerc (subscriber, #3071) [Link] (1 responses)

I know, I wrote it. Glad it is useful.

I'm really surprised it's not seen as more of an issue. How is one supposed to analyze intermittent faults, heisenbugs etc without the ability to debug crashes and hangs in release builds?

parallel linking still wanted

Posted Feb 5, 2025 4:14 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Thanks!

I think, most people just leave the debug symbols? They are not _that_ massive in Go.