Compilation with clang: clang do not recognise .end directive

[Vasily Postnicov]

SBCL cannot be compiled with clang. Since clang is primary compiler on FreeBSD it is impossible to compile sbcl on FreeBSD without additional manipulations.

The cause is that clang do not understand .end assembler directive from end of each src/runtime/arch-assem.S

.end is added by expanding END() macro which is defined in x86-assem.S as follows:

#if defined(LISP_FEATURE_UD2_BREAKPOINTS)
#define END()
#define TRAP ud2
#else
#define END() .end
#define TRAP int3
#endif

and in x86-64-assem.S as follows:

#if defined(LISP_FEATURE_DARWIN)
/* global symbol x86-64 sym(%rip) hack:*/
#define GSYM(name) name(%rip)
#define END()
#else
#define GSYM(name) $name
#define END() .end
#endif

Why it depends on LISP_FEATURE_UD2_BREAKPOINTS in x86? Can we just define END() on per compiler basis?

The other thing I am uncertain about is GCC Thread Local Storage used in FreeBSD. It seems that clang has this feature too. All thread-related tests pass when compiled with clang (when END() macro is commented).

Can I send a patch or there are underwater stones here?

[Stas Boukarev (stassats)]

What about removing this END() thing completely?

[Vasily Postnicov (shamaz-mazum)]

Oops I am sorry. When compiled with clang 3.3 I have many tests of debugger failed.

And, of course, clang *DOES* :)

Will try different combinations of compiler / END()s / features and say what I've got.

[Stas Boukarev (stassats)]

I removed .end altogether in fcf85c2d548fe22bdaccdade49b048e415a6d86a.

[Vasily Postnicov (shamaz-mazum)]

> I removed .end altogether

Thanks. It seems that test failures and .end are unrelated (According to http://tigcc.ticalc.org/doc/gnuasm.html .end is just and end of assembly file). Tried with gcc/clang with/without END()

It's just confusing that END() was defined so weird.

[Paul Khuong (pvk)]

The weirdness likely stems from the fact that (IIRC) the definition is
a workaround for darwin's `as` not acting like `gas`.

On Mon, Mar 17, 2014 at 2:19 PM, Vasily Postnicov
<email address hidden> wrote:
>> I removed .end altogether
>
> Thanks. It seems that test failures and .end are unrelated (According to
> http://tigcc.ticalc.org/doc/gnuasm.html .end is just and end of assembly
> file). Tried with gcc/clang with/without END()
>
> It's just confusing that END() was defined so weird.
>
> --
> You received this bug notification because you are subscribed to SBCL.
> https://bugs.launchpad.net/bugs/1293643
>
> Title:
> Compilation with clang: clang do not recognise .end directive
>
> Status in Steel Bank Common Lisp:
> Fix Committed
>
> Bug description:
> SBCL cannot be compiled with clang. Since clang is primary compiler on
> FreeBSD it is impossible to compile sbcl on FreeBSD without additional
> manipulations.
>
> The cause is that clang do not understand .end assembler directive
> from end of each src/runtime/arch-assem.S
>
> .end is added by expanding END() macro which is defined in x86-assem.S
> as follows:
>
> #if defined(LISP_FEATURE_UD2_BREAKPOINTS)
> #define END()
> #define TRAP ud2
> #else
> #define END() .end
> #define TRAP int3
> #endif
>
> and in x86-64-assem.S as follows:
>
> #if defined(LISP_FEATURE_DARWIN)
> /* global symbol x86-64 sym(%rip) hack:*/
> #define GSYM(name) name(%rip)
> #define END()
> #else
> #define GSYM(name) $name
> #define END() .end
> #endif
>
> Why it depends on LISP_FEATURE_UD2_BREAKPOINTS in x86? Can we just
> define END() on per compiler basis?
>
> The other thing I am uncertain about is GCC Thread Local Storage used
> in FreeBSD. It seems that clang has this feature too. All thread-
> related tests pass when compiled with clang (when END() macro is
> commented).
>
> Can I send a patch or there are underwater stones here?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/sbcl/+bug/1293643/+subscriptions