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

I'm also interested in this area as we're adapting our VAX Macro32
'assembler'
to LLVM x86-64 at the MCInst level.  These sorts of things happen all the time 
for me so having some underlying support is helpful.  We have our own 
parser/middle-end of course.

We'll also be adding some out-of-tree support for non-absolute expressions 
as well for OpenVMS.  We have ELF relocation extensions for Itanium to let 
that happen.

For example,

.long external_name1 - external_name2

OpenVMS has had this since the beginning (1970s) and we can't seem to shake
it.
I'm not sure anybody else would want this so we have to keep it local.


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
>