[PATCH] D20337: [MC] Support symbolic expressions in assembly directives

[James Y Knight via llvm-commits]

The .s does have a way to carry the location. GCC emits location lines
around inline asm, like this:
#APP
# 3 "/tmp/test-asm.c" 1
        cmp %ax, %ax
# 0 "" 2
#NO_APP

Clang doesn't do that. Clang emits for the same code:
        #APP
        cmpw    %ax, %ax
        #NO_APP

Emitting location directives that seems like it's really a separate patch,
IMO.

On Wed, May 25, 2016 at 10:29 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > That's not the case that I'm concerned about.
> >
> > Let's say it's an expression (TEST1 - TEST0 - 4) for which we don't know
> should cause an error until we generate an object. With this we will to
> output this to the file without checking. If it's a problem, we will
> absolutely error when we attempt to generate an object but we've lost the
> original location of the error and we'll instead get the location from the
> new file which we do not gaurantee to be the same.
>
> For the sake of argument lets say it is clang creating that expression.
>
> If someone is running "clang -S test.c && clang -c test.s" we will
> report an error in the .s. There is no way around it: the .s doesn't
> have a way to cary the location for use in the error message.
>
> If someone is running "clang -c test.c" we will not use the asm streamer.
>
> > This breaks the property that generating an assembly and then making an
> object file has the same output as just generating the object file directly.
>
> If there is no error, that property is not broken.
> If there is an error, that property doesn't exist already. It is
> perfectly possible to create a .s that will not assemble.
>
> If there is the desire to change that, what I think should happen is
> for -S to create and discard an object file in memory. Without
> creating an actual assembler we will never know for sure if a .s can
> or cannot be assembled, but that is independent from this change.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160525/7f933fd3/attachment.html>