[Bug libbacktrace/88745] Darwin lacks an implementation for libbacktrace

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88745

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Eric Gallager from comment #4)
> (In reply to Ian Lance Taylor from comment #3)
> > filetype.awk is just an AWK script.  See
> > https://www.gnu.org/software/gawk/manual/gawk.html.  A Mach-O file starts
> > with 0xfeedface (32-bit Mach-O) or 0xfeedfacf (64-bit Mach-O) in either
> > big-endian or little-endian order.
> 
> Does the endianness actually matter? Neither the elf nor pecoff cases seem
> to be duplicated for their opposite endiannesses... Also are the octal
> escape sequences necessary?

Mach-O files have 4 different magic numbers that indicate bit size and
endianness.

The file format and layout is described in /usr/include/mach-o/loader.h (and
the other roles in that directory add information on symbols etc.)

You can also look at libiberty/simple-object-mach-o.* (not quite sure why we
are not re-using stuff from there instead of inventing yet another binary file
reader).

** I have a significant (yet unposted) update to the
libiberty/simple-object-mach-o code to handle the LTO debug section copying -
which I can send to you if you like.

The values are not ascii - so some form of escape sequence will be needed.

endianness matters if:
(a) we would like to continue for things to work with powerpc (which I continue
to support and test)
(b) you don't want things to crash or misbehave if a PPC impl. is presented
with X86 or vice-versa.

If you write the code knowing this support is needed, the endianness and size
will not matter [much, at least] (since swapping and the size of a pointer can
be abstracted away).