What's going on in Apple LLVM-gcc x86 assembly?

assembly, c, llvm-gcc, macos, x86

Solution

Since the question is really about those odd labels and data and not really about the code itself, I'm only going to shed some light on them.

If an instruction of the program causes an execution error (such as division by 0 or access to an inaccessible memory region or an attempt to execute a privileged instruction), it results in an exception (not a C++ kind of exception, rather an interrupt kind of it) and forces the CPU to execute the appropriate exception handler in the OS kernel. If we were to totally disallow these exceptions, the story would be very short, the OS would simply terminate the program.

However, there are advantages of letting programs handle their own exceptions and so the primary exception handler in the OS handler reflects some of exceptions back into the program for handling. For example, a program could attempt to recover from the exception or it could save a meaningful crash report before terminating.

In either case, it is useful to know the following:

- the function, where the exception has occurred, not just the offending instruction in it

- the function that called that function, the function that called that one and so on

and possibly (mainly for debugging):

- the line of the source code file, from which this instruction was generated

- the lines where these function calls were made

- the function parameters

Why do we need to know the call tree?

Well, if the program registers its own exception handlers, it usually does it something like the C++ `try` and `catch` blocks:

fxn()
{
  try
  {
    // do something potentially harmful
  }
  catch()
  {
    // catch and handle attempts to do something harmful
  }
  catch()
  {
    // catch and handle attempts to do something harmful
  }
}

If neither of those `catches` catches, the exception propagates to the caller of `fxn` and potentially to the caller of the caller of `fxn`, until there's a `catch` that catches the exception or until the default exception handler that simply terminates the program.

So, you need to know the code regions that each `try` covers and you need to know how to get to the next closest `try` (in the caller of `fxn`, for example) if the immediate `try`/`catch` doesn't catch the exception and it has to bubble up.

The ranges for `try` and locations of `catch` blocks are easy to encode in a special section of the executable and they are easy to work with (just do a binary search for the offending instruction addresses in those ranges). But figuring out the next outer `try` block is harder because you may need to find out the return address from the function, where the exception occurred.

And you may not always rely on `rbp+8` pointing to the return address on the stack, because the compiler may optimize the code in such a way that `rbp` is no longer involved in accessing function parameters and local variables. You can access them through `rsp+something` as well and save a register and a few instructions, but given the fact that different functions allocate different number of bytes on the stack for the locals and the parameters passed to other functions and adjust `rsp` differently, just the value of `rsp` isn't enough to find out the return address and the calling function. `rsp` can be an arbitrary number of bytes away from where the return address is on the stack.

For such scenarios the compiler includes additional information about functions and their stack usage in a dedicated section of the executable. The exception-handling code examines this information and properly unwinds the stack when exceptions have to propagate to the calling functions and their `try`/`catch` blocks.

So, the data following `_main.eh` contains that additional information. Note that it explicitly encodes the beginning and the size of `main()` by referring to `Leh_func_begin1` and `Leh_func_end1-Leh_func_begin1`. This piece of info allows the exception-handling code to identify `main()'s` instructions as `main()'s`.

It also appears that `main()` isn't very unique and some of its stack/exception info is the same as in other functions and it makes sense to share it between them. And so there's a reference to `Leh_frame_common`.

I can't comment further on the structure of `_main.eh` and the exact meaning of those constants like `144` and `13` as I don't know the format of this data. But generally one doesn't need to know these details unless they are the compiler or the debugger developers.

I hope this give you an idea of what those labels and constants are for.

Problem

Original source