llvm dev - Apr 2016 - Backward references in assembly absolute expressions

While trying to compile an existing codebase which uses handwritten
assembly with LLVM, I ran into an issue around using backward references in
assembly absolute expressions. A simple example can be the following
snippet:

_foo:
  .fill 0x100
_bar:
  .fill _bar - _foo
_baz:
  .fill 0x100

While gas compiles this snippet without any errors, the integrated
assembler throws an error: expected absolute expression for _bar - _foo.

I haven't found any definition of absolute expression in gas manual, and
it's arguable whether this case should be considered an absolute
expression, but at the point of evaluating the directive, the addresses of
backward labels should be already known so this expression could be treated
as absolute. A quick search also revealed several bug reports related to
this issue so it seems like this use case is fairly common.

I'd be happy to try and implement the support for backward references in MC
(unless someone else is already working on this), but before I do invest
more time on this issue, I'd like to ask if this is desirable or if the
lack of support for backward references is intentional?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160419/3413ff4c/attachment.html>

I've created a patch which adds support for symbolic expressions in
absolute expressions which matches the behavior of GNU assembler, would
someone be willing to review it?

http://reviews.llvm.org/D20337

On Tue, Apr 19, 2016 at 2:19 PM Petr Hosek <phosek at chromium.org> wrote:
> While trying to compile an existing codebase which uses handwritten
> assembly with LLVM, I ran into an issue around using backward references in
> assembly absolute expressions. A simple example can be the following
> snippet:
>
> _foo:
>   .fill 0x100
> _bar:
>   .fill _bar - _foo
> _baz:
>   .fill 0x100
>
> While gas compiles this snippet without any errors, the integrated
> assembler throws an error: expected absolute expression for _bar - _foo.
>
> I haven't found any definition of absolute expression in gas manual,
and
> it's arguable whether this case should be considered an absolute
> expression, but at the point of evaluating the directive, the addresses of
> backward labels should be already known so this expression could be treated
> as absolute. A quick search also revealed several bug reports related to
> this issue so it seems like this use case is fairly common.
>
> I'd be happy to try and implement the support for backward references
in
> MC (unless someone else is already working on this), but before I do invest
> more time on this issue, I'd like to ask if this is desirable or if the
> lack of support for backward references is intentional?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160517/4561d77c/attachment.html>

Looping in people with at least some interest in this side of things...

On Tue, May 17, 2016 at 2:59 PM Petr Hosek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I've created a patch which adds support for symbolic expressions in
> absolute expressions which matches the behavior of GNU assembler, would
> someone be willing to review it?
>
> http://reviews.llvm.org/D20337
>
>
> On Tue, Apr 19, 2016 at 2:19 PM Petr Hosek <phosek at chromium.org>
wrote:
>
>> While trying to compile an existing codebase which uses handwritten
>> assembly with LLVM, I ran into an issue around using backward
references in
>> assembly absolute expressions. A simple example can be the following
>> snippet:
>>
>> _foo:
>>   .fill 0x100
>> _bar:
>>   .fill _bar - _foo
>> _baz:
>>   .fill 0x100
>>
>> While gas compiles this snippet without any errors, the integrated
>> assembler throws an error: expected absolute expression for _bar -
_foo.
>>
>> I haven't found any definition of absolute expression in gas
manual, and
>> it's arguable whether this case should be considered an absolute
>> expression, but at the point of evaluating the directive, the addresses
of
>> backward labels should be already known so this expression could be
treated
>> as absolute. A quick search also revealed several bug reports related
to
>> this issue so it seems like this use case is fairly common.
>>
>> I'd be happy to try and implement the support for backward
references in
>> MC (unless someone else is already working on this), but before I do
invest
>> more time on this issue, I'd like to ask if this is desirable or if
the
>> lack of support for backward references is intentional?
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160518/e6f070f5/attachment.html>

On 19 April 2016 at 17:19, Petr Hosek via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> While trying to compile an existing codebase which uses handwritten
assembly
> with LLVM, I ran into an issue around using backward references in assembly
> absolute expressions. A simple example can be the following snippet:
>
> _foo:
>   .fill 0x100
> _bar:
>   .fill _bar - _foo
> _baz:
>   .fill 0x100
>
> While gas compiles this snippet without any errors, the integrated
assembler
> throws an error: expected absolute expression for _bar - _foo.
>
> I haven't found any definition of absolute expression in gas manual,
and
> it's arguable whether this case should be considered an absolute
expression,
> but at the point of evaluating the directive, the addresses of backward
> labels should be already known so this expression could be treated as
> absolute. A quick search also revealed several bug reports related to this
> issue so it seems like this use case is fairly common.
>
> I'd be happy to try and implement the support for backward references
in MC
> (unless someone else is already working on this), but before I do invest
> more time on this issue, I'd like to ask if this is desirable or if the
lack
> of support for backward references is intentional?
I think MC is intentionally stricter, but this case shouldn't be too
hard to implement. Since this is uncommon, my suggestion would be to
just create MCFillFragment that takes a MCEXpr for size (or change the
existing one assuming it is still fast enough).

Cheers,
Rafael