[PATCH 3/5] gas: partly restore how current_location() had worked

[Maciej W. Rozycki]

On Tue, 26 Nov 2024, Jan Beulich wrote:

> >  Please refer these discussions:
> > 
> > <https://inbox.sourceware.org/binutils/alpine.DEB.1.10.1007240320070.29495@tp.orcam.me.uk/>
> > <https://inbox.sourceware.org/binutils/alpine.DEB.1.10.1007241701380.29495@tp.orcam.me.uk/>
> > <https://inbox.sourceware.org/binutils/alpine.DEB.1.10.1007241721120.29495@tp.orcam.me.uk/>
> > <https://inbox.sourceware.org/binutils/alpine.DEB.1.10.1007242332460.29495@tp.orcam.me.uk/>
> > <https://inbox.sourceware.org/binutils/alpine.DEB.1.10.1007260105250.29495@tp.orcam.me.uk/>
> > 
> > for the rationale behind this change and the other three in the series.  
> > There is a test case for the whole series included in 4/4.  Arguably the 
> > example given in 2.5/4 should have been made a proper test case as well.  
> > Please feel free to use it now.
> 
> For the .eqv case current_location() keeps using dot_symbol, even though -
> see the cover letter of the series - I'm unconvinced dot_symbol is being
> maintained as it should be (or alternatively dot_frag / dot_value aren't).

 I agree, we're inconsistent here.  I do hope you've found the discussions 
referred useful.

> To give some background: I first tried to actually get rid of dot_symbol
> again, yet that didn't work out as easily as I had hoped.

 I think it's `dot_frag'/`dot_value' actually that should go as both data 
objects can be retrieved from `dot_symbol' while `dot_symbol' can also be 
used in other ways.

  Maciej