[llvm-dev] RFC: [MC] Calculate difference of symbols in two consecutive MCDataFragments

[James Y Knight via llvm-dev]

I'm a bit confused by this. All of the test cases, except the one
(directive_if.s) you've only just added seem to already work in llvm-as
prior to the patch. AFAICT, there should be no need to compute deltas
across MC fragments. (GNU as certainly doesn't do anything complex like
that). It's hard for me to tell what the issue being reported in
https://llvm.org/PR43795 is, because there's no standalone reproduction,
and extracting the snippet reported and attempting to assemble, appears to
work already as well.

The other problem, in https://llvm.org/PR41825 is clear, at least -- this
fails with "error: expected absolute expression", which is unexpected and
incorrect:

foo:

.if (. - foo) != 0

        nop

.endif


I believe https://reviews.llvm.org/D70062 is a simple fix for that problem.


On Tue, Nov 5, 2019 at 4:20 PM Reid Kleckner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I think you meant to link to this patch here:
> https://reviews.llvm.org/D69411
>
> There's too much discussion for me to read and understand, but I think
> what would help the most is developing a clear summary of what the gnu
> assembler's behavior is. Do they defer evaluation of the if condition? Do
> they under or overestimate offsets in the ambiguous cases? Or do they just
> error out cases where there are relaxable fragments between labels? That
> should help us pick a more general direction for this feature.
>
> On Tue, Nov 5, 2019 at 12:08 PM Jian Cai via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hello,
>>
>> I've been trying to add support to the integrated assembler to handle
>> cases like below
>>
>> foo:instr; .if . - foo; instr; .endif
>>
>> when the dot symbol and foo are assigned to consecutive MCDataFragments
>> <https://github.com/ClangBuiltLinux/linux/issues/744>. I have a patch
>> <https://reviews.llvm.org/D6941> under review. And even though it seems
>> to solve the problem, the concern is it complicates the code and we would
>> like to know if there is more decent way to handle this. Please feel free
>> to share your thoughts.
>>
>> Thanks,
>> Jian
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20191110/5673de5b/attachment-0001.html>