core-explorer

This is very cool. I am a big believer in tools analyzing a sequence of heap snapshots to automate the time-consuming parts of manual debugging.

I am working on doing something similar in C++, where there is an additional obstacle of recreating the objects from a memory snapshot without runtime support.

The extensions were voted into the upcoming DWARF 6 standard, e.g.https://dwarfstd.org/issues/211206.1.html

debugging information is more precise than line numbers, it usually conveys line and column in a source file.

Some debuggers make use of it when displaying the current program state, the major debuggers do not allow you to step into a specific sub-call on a line (e.g. skip function arguments and go straight to the outermost function call). This is purely a UI issue, they have enough information. I believe the nnd debugger has implemented selecting the call to step into.

Addr2line could be amended. I am working on my own debugger and I keep re-implementing existing command line tools as part of my testing strategy. A finer-grained addr2line sounds like a good exercise.

I got tired of debugging the same kind of bugs over and over again. I can't make a dent in the overall quality of the legacy code base, so I decided to start writing a tool to automate the boring parts of debugging memory corruption and memory leaks (no LLM involved so far).

When you try to solve one problem involving two objects in three-dimensional space, you have a six-dimensional problem space. If you have two moving objects, you have a twelve-dimensional problem space. Higher dimensional spaces show up everywhere when dealing with real-life problems.

We usually don't talk about "the dimensions", we talk about the general case: n-dimensional spaces (theorems covering all dimensions simultaneously) or infinite-dimensional spaces (individual spaces covering all finite-dimensional spaces).

Of course, when you try to generalize your theorems you are also interested in the cases where generalization fails. In this case, there is something that happens in a 2-dimensional space, in a 6-, 14- or 30-dimensional space. Mathematicians would say "it happens in 2, 6, 14 or 30 dimensions". I never noticed that this is jargon specific to mathematicians.

Problems in geometry tend to get (at least) exponentially harder to solve computationally as the dimensions grow, e.g. the number of vertices of the n-dimensional cube is literally the exponential of base 2. Which is why they discovered something about 126-dimensional space now, when the results for lower dimensions have been known for decades.

I know how to see the source in my debugger and I know how to see the disassembly. Which IDE will show me the compiler's internal IR if I want something in between?

I felt under-challenged last year and realized that it is because I spend too much time debugging and not enough time writing software. So I did the obvious thing and spent the holiday season writing a new debugging tool instead of playing video games.