All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: David Rheinsberg <david@readahead.eu>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Dave Hansen <dave.hansen@linux.intel.com>,
	Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86/insn_decoder_test: allow longer symbol-names
Date: Wed, 25 Jan 2023 12:30:41 +0100	[thread overview]
Message-ID: <Y9ES4UKl/+DtvAVS@gmail.com> (raw)
In-Reply-To: <320c4dba-9919-404b-8a26-a8af16be1845@app.fastmail.com>


* David Rheinsberg <david@readahead.eu> wrote:

> Increase the allowed line-length of the insn-decoder-test to 4k to allow
> for symbol-names longer than 256 characters.
> 
> The insn-decoder-test takes objdump output as input, which may contain
> symbol-names as instruction arguments. With rust-code entering the
> kernel, those symbol-names will include mangled-symbols which might
> exceed the current line-length-limit of the tool.
> 
> By bumping the line-length-limit of the tool to 4k, we get a reasonable
> buffer for all objdump outputs I have seen so far. Unfortunately, ELF
> symbol-names are not restricted in length, so technically this might
> still end up failing if we encounter longer names in the future.
> 
> My compile-failure looks like this:
> 
>     arch/x86/tools/insn_decoder_test: error: malformed line 1152000:
>     tBb_+0xf2>
> 
> ..which overflowed by 10 characters reading this line:
> 
>     ffffffff81458193:   74 3d                   je     ffffffff814581d2 <_RNvXse_NtNtNtCshGpAVYOtgW1_4core4iter8adapters7flattenINtB5_13FlattenCompatINtNtB7_3map3MapNtNtNtBb_3str4iter5CharsNtB1v_17CharEscapeDefaultENtNtBb_4char13EscapeDefaultENtNtBb_3fmt5Debug3fmtBb_+0xf2>
> 
> Signed-off-by: David Rheinsberg <david@readahead.eu>
> ---
>  arch/x86/tools/insn_decoder_test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/tools/insn_decoder_test.c b/arch/x86/tools/insn_decoder_test.c
> index 472540aeabc2..366e07546344 100644
> --- a/arch/x86/tools/insn_decoder_test.c
> +++ b/arch/x86/tools/insn_decoder_test.c
> @@ -106,7 +106,7 @@ static void parse_args(int argc, char **argv)
>  	}
>  }
>  
> -#define BUFSIZE 256
> +#define BUFSIZE 4096

That hard-coded constant is a bit lame and will cause trouble the minute 
*that* size is exceeded - don't we have some more natural figure, such as 
KSYM_SYMBOL_LEN?

Thanks,

	Ingo

  reply	other threads:[~2023-01-25 11:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-24 11:04 [PATCH] x86/insn_decoder_test: allow longer symbol-names David Rheinsberg
2023-01-25 11:30 ` Ingo Molnar [this message]
2023-01-27 10:27   ` David Rheinsberg
2024-02-20 17:07     ` Miguel Ojeda
2024-04-08 12:51       ` Danilo Krummrich
2024-04-08 15:22         ` Sergio González Collado
2024-04-08 15:30           ` Sergio González Collado
  -- strict thread matches above, loose matches on Subject: below --
2024-11-29 15:40 Richard W.M. Jones
2024-12-24 15:24 ` Andrew Halaney

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=Y9ES4UKl/+DtvAVS@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@readahead.eu \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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.