In the GDB code compilation team, which language constructs behave exactly as if they were present in the original source?

Question

GDB recently introduced a compile command to enter code at runtime, see this answer for requirements and a minimal example.

But I noticed that some things do not work, as if I wrote them in the source code at the current location:

• compile code return; does not end the current function, but only the entered code.

  Hypothesis: the code runs on a new stack stack, but one in which local variables are still visible.

• Error registering changes, for example:

   compile code asm volatile ("mov $0x123, %rbp"); p $rbp 

  Conclusion: not 0x123 .

  Hypothesis: registers are saved and restored when the function starts.

In addition, the documentation clearly explains that the entered code characters and types are not visible from the outside.

So, what is the general theory / complete list of those constructs that "don't work"?

The GNU Cauldron presentation of this function provides an overview of the use of functions and internal components: video , presentation

This function is implemented in the compile/ source subdirectory of 7.9.1 GDB.

Answer 1

The compile command works by issuing a new function, compiling it with gcc, and then calling the function from gdb ("calling incomplete functions" in gdb lingo).

The code generator has some special functions that allow you to access local variables. In particular, it converts DWARF location expressions to C. Register references are translated into field references in a special struct . gdb organizes copying the appropriate registers to an instance of this structure when making a lower call. At the end of the call, it copies the registers back - this allows you to write local variables.

This description should, I think, clarify what will work and what will not. I would expect return and other flow control operations ( break , continue , goto ) to not work.

Writing to a register should work, but only for registers, which are necessary for some expression of location. Perhaps this can be fixed; although I believe that now, for performance reasons, only the necessary registers are transferred.

I don't know what will happen if your compiled code calls longjmp or throw (well, when C ++ is implemented). Probably crazy.

One thing worth knowing is that this code was designed so that a future patch could add compiled breakpoint conditions, perhaps in combination with something like dyninst.