gas: unhelpful sprint_value() behavior

[Jan Beulich]

Nick,

On 09.04.2021 17:40, Nick Clifton wrote:
>> Since addressT, valueT, and bfd_vma are all the same (nowadays?) anyway
>> and since there are pretty few uses of the function, would there be any
>> objection to dropping it, making the callers use sprint_vma() instead?
> 
> In the past I had thought that changes like this were obvious improvements.
> Then I started seeing bug reports from users complaining about the change in
> behaviour of a tool that they had been using for years, so now I am bit more
> wary.

I can certainly see such expectations for tools the primary purpose of
which is to produce textual output. gas doesn't fall in this group,
and at least on x86 we've been changing diagnostic text all the time
without me being aware of complaints. Personally I think it's the
nature of diagnostics that they may change over time - getting better
(hopefully), getting split to be more precise for certain situations,
or - when there's more than one issue with a single line - ordering of
checks leading to one getting replaced by another. Just to give a few
examples.

Therefore, no, I don't think this ought to be a concern here. In any
event, if ...

> My suggestion would be that rather than making a blanket change you either
> provide a new command line option to determine the desired behaviour and/or
> a configure time option to select the default behaviour.

... I'd need to go this far, I guess I'd rather adapt my testcase and
make it accept the (imo) meaningless decimal output as well. In no
case am I going to touch configure unless I absolutely can't avoid it.

> On a related note, there is an open PR about similar behaviour in readelf:
> 
>    https://sourceware.org/bugzilla/show_bug.cgi?id=27672
> 
> This is probably going to be resolved by a new command line option for readelf,
> so it might be nice if a similar naming scheme is used in gas, assuming that
> you agree with the new-option idea.

Well, the "sym" in the proposed --sym-base would make it look as if
this option is relevant only for symbol values, but not other
entities.

Another concern with introducing such an option to gas would be that
the expectation then might validly be that all respective numeric
output is controlled by it. This would be too large a project for
the little bit of time I have for binutils work.

Jan