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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191105/aa358cc0/attachment.html>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191105/760cf910/attachment.html>

Yes, thanks for the correction.

Thanks,
Jian

On Tue, Nov 5, 2019 at 1:20 PM Reid Kleckner <rnk at google.com> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191105/c124194d/attachment.html>

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>