[llvm-dev] RFC: [MC] Calculate difference of symbols in two consecutive MCDataFragments
Jian Cai via llvm-dev
llvm-dev at lists.llvm.org
Mon Nov 11 11:57:45 PST 2019
On Sun, Nov 10, 2019 at 1:35 PM James Y Knight <jyknight at google.com> wrote:
> 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.
Ah, I accidentally removed a nop instruction required to reproduce the
issue. I have updated my test cases. Thanks for catching this.
> The other problem, in https://llvm.org/PR41825 is clear, at least -- this
> fails with "error: expected absolute expression", which is unexpected and
> .if (. - foo) != 0
> I believe https://reviews.llvm.org/D70062 is a simple fix for that
Thanks for the fix!
> 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:
>> 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:
>>> 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.
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev