Debugging facilities for the linking process about mold

[deliciouslytyped]

Assuming something like the configuration staging in #4 were to be implemented, at the least this would allow deeper inspection of the linker configuration state?

I suppose that's largely unrelated but you've already mentioned pre-caching other files.

[rui314]

Debugging a linker is indeed hard, and I don't have a good idea to improve it significantly. In the early stage of development of mold, I added --print-map option to dump the layout of an output file, which was helpful sometimes. But most of the cases, buts are in a subtle feature or a lack thereof, and it often surfaces as a mysterious crash before the control reaches main. I don't know how to debug that kind of issues efficiently.

[matu3ba]

FYI: You can take a look how https://github.com/kubkon/zig-snapshots and the compiler does it. Not sure, if ~1.5k LOC are worth it.

I don't know how to debug that kind of issues efficiently.

Often printf logging with printf-functions of the state is the best option, since debugging-based tracing does not exist due to debugger ecosystems being incomplete and/or slow. So unfortunately one cant just tell gdb/lldb with a python function to "ftrace the function arguments".

[deliciouslytyped]

in the meantime, at least on NixOS, generally during packaging work, most of my linking issues are system integration related, and running ld in verbose mode:

• dumps the linker script currently being run,
• lists the paths searched for libraries

Inspecting the path dump tends to solve a large portion of my problems.
This is, of course, a large but limited subset of issues.

[rui314]

I think this item is not actionable, so closing this issue.