Clang assembler missed features

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Clang assembler missed features

Leonard Chan via cfe-dev
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
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang assembler missed features

Leonard Chan via cfe-dev
>
> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang assembler missed features

Leonard Chan 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang assembler missed features

Leonard Chan via cfe-dev
In reply to this post by Leonard Chan via cfe-dev
Hello,


> 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/

Ok, it seems that we actually don't need them. One problem less.

> - 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.

I understand the problem. We use these .if to verify some conditions
related to the size of some parts of the code:

        .macro check_vector_size since
         .if (. - \since) > (32*4))
               error "Vector exceeds 32 instructions"
        .endif

I suppose GNU As does some strange thing with .if to avoid the problem
(some delayed evaluation?).

Other thing that I didn't commented in the previous mail is related to
preprocesed assembler files, where consecutive strings are not dealt as
one string, as it is mandatory in C/C++ and GNU as does. This is not a
big problem for us, because we can change the code where we use that.

Anyway, thank you for your answer.


Best regards,
Roberto
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev