Re: MPS: assertion failed: header_type (h) != IGC_OBJ_FWD

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Pip Cet <pipcet@protonmail.com> writes:

> On Friday, July 19th, 2024 at 04:38, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>> Gerd Möllmann gerd.moellmann@gmail.com writes:
>> 
>> > Andrea Corallo acorallo@gnu.org writes:
>> > 
>> > > > Let's see how long igc survives this time :-).
>> > > 
>> > > Hi Gerd,
>> > > 
>> > > if you want to use '__builtin_unwind_init' be aware that this GCC bug
>> > > I've found sometime ago [1] might make the builtin ineffective. It
>> > > might not effect your generated code but in case you need you can see
>> > > how we work it around in 'flush_stack_call_func'.
>> > > 
>> > > Regards
>> > 
>> > Thanks, that could become important at some point on platforms other
>> > than macOS. AFAIK, one cannot build Emacs with GCC on newer versions of
>> > macOS because the SDK is incompatible with GCC, so GCC is out of the
>> > picture.
>> > 
>> > I haven't heard yet of anyone else having problems of the sort I have
>> > here on macOS on other platforms. But maybe that comes up later.
>> 
>> 
>> It didn't help, and no more ideas at the moment :-(.
>
> Can you try compiling with -fno-omit-frame-pointer? I just spent
> entirely too much time tracing down a bug in my build to a missing
> option (of the same name) to x86_64 gcc. The frame pointer is stored
> in a mangled format by setjmp() on both darwin and glibc systems, and
> that caused weird problems (and since gcc generates different code
> with and without "-g", I had to do that without proper debugger
> support...)

Thanks for letting me know! That indeed sounds like a candidate.

I wonder what __builtin_unwind_init does with the frame pointer. Using
it (in MPS itself) definitely has some effect on my system, although it
apparently is not a complete fix. But maybe there's more than one bug.
Hmm.

> Anyway, I think both architectures "allow" using the frame pointer
> register, so we're probably going to have to enforce that option,
> which will limit us to clang and gcc compilers unless someone figures
> out the configure magic...

The macOS arm ABI says

  The ARM standard delegates certain decisions to platform designers.
  Apple platforms adhere to the following choices:

  The platforms reserve register x18. Don’t use this register.

  The frame pointer register (x29) must always address a valid frame
  record. Some functions — such as leaf functions or tail calls — may opt
  not to create an entry in this list. As a result, stack traces are
  always meaningful, even without debug information.

I'll try the -fno-omit-frame-pointer anyway. Maybe I'm misinterpreting
that paragraph.