Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add labels around call sites (+ some background on DWARF call site support) #2316
This pull request generalises the existing support in the
Emitting comprehensive DWARF information for all call sites enables many more variables to be available and/or printed properly in the debugger than would otherwise be the case. This behaviour relies on the debugger being able to answer the following question. Suppose we are in some function that has associated with it a stack frame (known as the "current frame"). There is a previous (older) frame immediately above us on the stack which can be discovered by unwinding. The question is whether that previous frame corresponds to the caller of the function. (It might not because there may have been one or more tail calls in the middle.) gdb can provide various answers to this question, one of which is "definitely yes", if the DWARF information is comprehensive enough. This requires the compilier to describe all call sites that might be involved in such stack frame relations and to say whether or not they are tail calls. The OCaml compiler, after the DWARF patches, emits sufficient information for gdb to be able to do this.
This has two implications that are very useful in practice:
@stedolan Could you take a first pass of review please? patdiff is probably helpful for this one. There is some duplication for the "
I added a couple of
Call sites produced in the emitter (e.g.
lthls left a comment
I've reviewed the patch and it is correct.
But, I'm afraid I find it very unpleasant that the patch contains a lot of code that is duplicated, and relies on an invariant that is neither dynamically checked nor statically prevented.
I'm still approving this, because there's a lot of work on the DWARF information generation that still needs to be done and I don't want to hold it up more than necessary, but when time permits I would like to see some improvements made on at least two issues:
I don't know anything about this particular PR, but in my opinion this reasoning is problematic. @gasche made a similar observation recently and I also feel that merging suboptimal code with the hope that it will be cleaned up later is not the way to go.