All of lore.kernel.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: jniethe5@gmail.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()
Date: Tue, 31 May 2022 17:27:15 -0500	[thread overview]
Message-ID: <20220531222715.GT25951@gate.crashing.org> (raw)
In-Reply-To: <20220531065936.3674348-1-mpe@ellerman.id.au>

Hi!

On Tue, May 31, 2022 at 04:59:36PM +1000, Michael Ellerman wrote:
> More problematically it doesn't compile at all with GCC 12, due to the
> fact that it returns the char buffer declared inside the macro:

It returns a pointer to a buffer on stack.  It is not valid C to access
that buffer after the function has returned (and indeed it does not
work, in general).

> A simpler solution is to just print the value as an unsigned long. For
> normal instructions the output is identical. For prefixed instructions
> the value is printed as a single 64-bit quantity, whereas previously the
> low half was printed first. But that is good enough for debug output,
> especially as prefixed instructions will be rare in practice.

Prefixed insns might be somewhat rare currently, but it will not stay
that way.

It is not hard to fix the problem here?  The only tricky part is that
ppc_inst_as_ulong swaps the two halves for LE, for as far as I can see
no reason at all :-(

If it didn't it would be easy to detect prefixed insns (because they
then are guaranteed to be > 0xffffffff), and it is easy to print them
with a space between the two opcodes, with a utility function:

void print_insn_bytes_nicely(unsigned long insn)
{
	if (insn > 0xffffffff)
		printf("%08x ", insn >> 32);
	printf("%08x", insn & 0xffffffff);
}

or something like that.


Segher

  reply	other threads:[~2022-05-31 22:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-31  6:59 [PATCH] powerpc/64: Drop ppc_inst_as_str() Michael Ellerman
2022-05-31 22:27 ` Segher Boessenkool [this message]
2022-06-01 10:43   ` Michael Ellerman
2022-06-01 16:20     ` Segher Boessenkool
2022-06-02  3:01       ` Jordan Niethe
2022-06-02  8:46         ` Segher Boessenkool
2022-06-03  5:03           ` Jordan Niethe
2022-06-03 12:49             ` Segher Boessenkool
2022-06-01  3:03 ` Bagas Sanjaya
2022-06-01  3:30   ` Bagas Sanjaya
2022-07-04 11:33 ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220531222715.GT25951@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=jniethe5@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.