[PATCH][MIPS][Committed] Fix PR/gas 25539 fix_loongson3_llsc: fix when target has multi labels

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH][MIPS][Committed] Fix PR/gas 25539 fix_loongson3_llsc: fix when target has multi labels

Paul Hua
When there is multi-labels on the same insn, the current code
will take care about the last one. it may cause that no sync
is added at the target.

Here we scan all labels with same value of
   S_GET_VALUE(label_list->label)
by label_list->next.

2020-02-28  YunQiang Su  <[hidden email]>

    PR gas/25539
    * config/tc-mips.c (fix_loongson3_llsc): Compare label value
    to handle multi-labels.
    (has_label_name): New.

0001-MIPS-fix_loongson3_llsc-fix-when-target-has-multi-la.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][MIPS][Committed] Fix PR/gas 25539 fix_loongson3_llsc: fix when target has multi labels

Maciej W. Rozycki
On Fri, 28 Feb 2020, Paul Hua wrote:

> When there is multi-labels on the same insn, the current code
> will take care about the last one. it may cause that no sync
> is added at the target.

 Why do you need to set an arbitrary limit as to the number of labels
handled (MAX_LABELS_SAME)?  This handles user-supplied input, so we can't
predict how many there will be at most.  What happens if the limit has
been exceeded?

 We should avoid setting unnecessary limits, as per our coding standards:
<https://www.gnu.org/prep/standards/standards.html#Semantics>.

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][MIPS][Committed] Fix PR/gas 25539 fix_loongson3_llsc: fix when target has multi labels

YunQiang Su-2
Maciej W. Rozycki <[hidden email]> 于2020年3月17日周二 上午9:49写道:
>
> On Fri, 28 Feb 2020, Paul Hua wrote:
>
> > When there is multi-labels on the same insn, the current code
> > will take care about the last one. it may cause that no sync
> > is added at the target.
>
>  Why do you need to set an arbitrary limit as to the number of labels
> handled (MAX_LABELS_SAME)?  This handles user-supplied input, so we can't

Yes. It is a problem. I did it fellow the scheme as MAX_LLSC_RANGE.
Maybe that we should use dynamic allocated memory to hold both of them.

> predict how many there will be at most.  What happens if the limit has
> been exceeded?

If exceeded the workaround won't work, aka no `sync' will be insert in
this case.

>
>  We should avoid setting unnecessary limits, as per our coding standards:
> <https://www.gnu.org/prep/standards/standards.html#Semantics>.
>
>   Maciej