[llvm-dev] Backward references in assembly absolute expressions
John Reagan via llvm-dev
llvm-dev at lists.llvm.org
Wed May 18 07:10:33 PDT 2016
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
.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?
> 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
>> .fill 0x100
>> .fill _bar - _foo
>> .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
More information about the llvm-dev