Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

[...]

 [re-adding the list]

 Hi Jimmy,

 thanks for the patch.

 So I guess is clear this is unrelated to circular lists and probably
 disassemble is just broken for every native compiled function in this
 configuration.

 We might have other architecture+OS where function labels start with '_'
 but so far the patch LGTM, I just suggest a small nit.

 > diff --git a/lisp/emacs-lisp/disass.el b/lisp/emacs-lisp/disass.el
 > index 6ac76f1c19..d0e3bf7bf4 100644
 > --- a/lisp/emacs-lisp/disass.el
 > +++ b/lisp/emacs-lisp/disass.el
 > @@ -95,6 +95,7 @@ disassemble-internal
 >                (re-search-forward (concat "^.*"
 >                                           (regexp-quote
 >                                            (concat "<"
 > +                                                  (if (eq system-type 'darwin) "_")
                                                      ^^^
                                                      I'd use `when' here.
 >                                                    (comp-c-func-name
 >                                                     (subr-name obj) "F" t)
 >                                                    ">:"))))

 Do you aready have copyright assignment?

 Best Regards

   Andrea

I do have an existing copyright assignment. No objection to using a when there, would you like me to submit a new patch
or you are fine with editing it yourself?

If you could provide a complete patch (including Changelog entry) that
would be appreciated thanks (please see the CONTRIBUTE file if in
doubt).  I'll be happy to install your patch if you don't have write
access.

As to whether this is related to circular lists, I'm not so sure yet.

This is certanly not related to circular lists, this is just about how
lables are named on this specific triplet.

There's definitely something in native compilation
that compiles code that behaves differently when circular lists are involved, I just haven't found out what interaction
with circular lists will result in compilation failure or optimizing the result away. Any clues for what I should try is
much appreciated.

If you have some code/package that behaves differently byte vs native
compiled you should be able to identify the function causing the
difference when executed.  Once that is done we could start
investigating.

Regards

  Andrea

Here's a new patch. Thanks in advance for installing it.