mbox series

[0/5] gas: dot handling

Message ID a6ee102d-02c4-4af3-b05b-008084ff7130@suse.com
Headers
Series gas: dot handling |

Message

Jan Beulich Nov. 22, 2024, 12:38 p.m. UTC 
  The fallout from dealing with PR gas/27217 has kept bothering me, so I
finally took the time to see whether we can't get things into better
shape. Before it goes in, especially the naming and defaulting aspects
(see the last patches for a respective remark) may want sorting, as in:
potentially doing a little differently. Input appreciated.

1: gas: streamline expr_build_dot()
2: MMIX: use current_location() directly
3: gas: partly restore how current_location() had worked
4: gas: introduce deferred expression evaluation mode latching dot
5: aarch64: re-work PR gas/27217 fix again

Further observations:

Shouldn't dot_symbol and dot_frag/dot_value remain in sync, i.e. be updated at
the same time? The fragment dot_symbol references typically is different at all
times when listings are enabled.

Do we really need both define_sym_at_dot() and symbol_set_value_now()? Their
sole differences being that the latter
- also works for local symbols,
- uses symbol_set_frag() and thus S_CLEAR_WEAKREFR() (where it's unclear to me
  why such a symbol would need weakrefr cleared, but one passed to
  define_sym_at_dot() wouldn't).

Jan

Comments

Maciej W. Rozycki Dec. 4, 2024, 1:55 a.m. UTC | #1 
On Fri, 22 Nov 2024, Jan Beulich wrote:

> Shouldn't dot_symbol and dot_frag/dot_value remain in sync, i.e. be updated at
> the same time? The fragment dot_symbol references typically is different at all
> times when listings are enabled.

 There is data duplication here and as noted in a replies to 1/5 and 3/5 I 
think ultimately we should merge this information into one piece and given 
that `dot_symbol' carries everything that `dot_frag'/`dot_value' do I feel 
it's the latter pair that should go with all the references updated to use 
`dot_symbol' instead.

  Maciej