[PATCH 4/4] x86: replace global scratch buffer

[H.J. Lu]

On Mon, Jun 13, 2022 at 7:55 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 13.06.2022 15:59, H.J. Lu wrote:
> > On Fri, Jun 10, 2022 at 6:36 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> With its movement to the stack, and with the subsequent desire to
> >> initialize the entire instr_info instances, this has become doubly
> >> inefficient. Individual users have better knowledge of how big a buffer
> >> they need, and in a number of cases going through an intermediate buffer
> >> can be avoided altogether.
> >>
> >> Having got confirmation that it wasn't intentional to print memory
> >> operand displacements with inconsistent style, print_displacement() is
> >> now using dis_style_address_offset consistently (eliminating the need
> >> for callers to pass in a style).
> >>
> >> While touching print_operand_value() also convert its "hex" parameter to
> >> bool. And while altering (and moving) oappend_immediate(), fold
> >> oappend_maybe_intel_with_style() into its only remaining caller. Finally
> >> where doing adjustments, use snprintf() in favor of sprintf().
> >> ---
> >> While doing the conversion I came to notice that print_operand_value()'s
> >> "hex" parameter has only ever passed "true" to it. I wonder why this
> >> parameter still exists.
> >>
> >
> > Andrew,
> >
> > Do you have follow-up patches to pass "false" to print_operand_value?
>
> I don't think that's related to Andrew's work. Even when looking at plain
> 2.37 (which I'm sure predates any of his work) I see only 1 ever passed
> as the argument. Going very far back (2.16) I see varying arguments. I
> therefore wonder whether the parameter simply wasn't cleaned up when the
> last party (possibly) passing 0 / false was removed / replaced.
>

It was changed to always use hexadecimal for

https://sourceware.org/bugzilla/show_bug.cgi?id=4430

We can remove the argument.


-- 
H.J.