[cfe-dev] Clang assembler missed features

[Nirav Davé via cfe-dev]

FYI, an initial patch for handling some assembler-time absolute expressions
for parsing is is being discussed here (https://reviews.llvm.org/D45164).

-Nirav

On Mon, Apr 16, 2018 at 12:32 PM Peter Smith via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> >
> > Hi,
> >
> >
> > I work in arm in an open source project called TF [1], and we support
> > compilation with clang.  We want to get rid of GNU tools when a clang
> > toolchain is used, but we found some problems when we try to use the
> > clang assembler:
> >
> >          - .func, .endfunc and .struct  directives are not supported
> >          - substraction of relative labels doesn't produce absolute
> >            values
> >
> >                  .if (. - \begin) > 32)
> >
> >                  generates 'error: expected absolute expression' message
> >
> > Is clang going to support these features?
> >
> > Best regards,
> >
> >
> > [1] https://github.com/ARM-software/arm-trusted-firmware
>
> Hello Roberto,
>
> Although I can't speak for the whole community, my predictions:
> - .func and .endfunc are unlikely as this is documented only to do
> something when the stabs debugging is enabled and clang is unlikely to
> support stabs. See https://sourceforge.net/p/libjpeg-turbo/bugs/72/
>
> - .struct seems feasible, but I don't know if anyone has any plans to
> implement it.
>
> - Subtraction of relative labels is unlikely in a .if statement. MC
> can produce absolute values for relative labels in some cases but it
> requires a layout. Instruction relaxation, such as turning a 16-bit
> Thumb branch into a 32-bit Thumb 2 branch if the distance requires it,
> means that the distance between 2 labels isn't known until the layout
> finalises. For .if the expression evaluation needs to occur before
> relaxation as the result of the .if could affect relaxation. In theory
> it could be possible to alter the assembler to calculate part of the
> layout inline and handle some expressions, but I don't think that the
> disruption to the implementation would be worth it.
>
> Peter
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180416/4b3e9333/attachment.html>