parallel linking still wanted
parallel linking still wanted
Posted Feb 4, 2025 23:16 UTC (Tue) by ringerc (subscriber, #3071)In reply to: parallel linking still wanted by mathstuf
Parent article: GNU Binutils 2.44 Released
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.
Posted Feb 4, 2025 23:49 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
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.
Posted Feb 5, 2025 2:52 UTC (Wed)
by ringerc (subscriber, #3071)
[Link] (3 responses)
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.
Posted Feb 5, 2025 3:31 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
There are workarounds: https://github.com/golang/go/issues/51692
Posted Feb 5, 2025 3:54 UTC (Wed)
by ringerc (subscriber, #3071)
[Link] (1 responses)
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?
Posted Feb 5, 2025 4:14 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I think, most people just leave the debug symbols? They are not _that_ massive in Go.
parallel linking still wanted
parallel linking still wanted
parallel linking still wanted
parallel linking still wanted
parallel linking still wanted