[PATCH] x86/tools: Use a longer buffer for insn_decoder_test

[PATCH] x86/tools: Use a longer buffer for insn_decoder_test

[Mitchell Levy]

Use a 1024 byte buffer for parsing objdump output lines to accommodate
long symbols created by rust doctests.

The number 1024 is based on giving a healthy margin above KSYM_NAME_LEN
to accommodate angle brackets, addresses, and whitespace.

---
Rust doctests can result in very long symbol names, which results in
very long lines in objdump output, such as:
<__pfx__RINvNtCshBBT4i9RzFA_4core3ptr13drop_in_placeINtNtNtCskPkSD4WGMmy_6kernel4sync3arc3ArcINtNtNtNtBN_5block2mq7tag_set6TagSetNtNvNvNvCs8MySzWyGC07_25doctests_kernel_generated33rust_doctest_kernel_block_mq_rs_04main42__doctest_main_rust_kernel_block_mq_rs_58_011MyBlkDeviceEEEB23_>:ffffffff818bb250

Currently, fgets will truncate on the first read of this line (but this
is fine since we see it starts with '<' and continue the loop), but on
the second we get "rs_58_011MyBlkDeviceEEEB23_>:ffffffff818bb250", which
is treated as malformed. 

Signed-off-by: Mitchell Levy <levymitchell0@gmail.com>
---
 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..18601b3c5037 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 1024
 
 int main(int argc, char **argv)
 {

---
base-commit: 37c5695cb37a20403947062be8cb7e00f6bed353
change-id: 20241118-insn-decoder-test-len-fix-0a8c622e79d4

Best regards,
-- 
Mitchell Levy <levymitchell0@gmail.com>

Re: [PATCH] x86/tools: Use a longer buffer for insn_decoder_test

[Miguel Ojeda]

On Wed, Nov 20, 2024 at 11:33 PM Mitchell Levy <levymitchell0@gmail.com> wrote:
>
> Use a 1024 byte buffer for parsing objdump output lines to accommodate
> long symbols created by rust doctests.
>
> The number 1024 is based on giving a healthy margin above KSYM_NAME_LEN
> to accommodate angle brackets, addresses, and whitespace.
>
> ---
> Rust doctests can result in very long symbol names, which results in
> very long lines in objdump output, such as:
> <__pfx__RINvNtCshBBT4i9RzFA_4core3ptr13drop_in_placeINtNtNtCskPkSD4WGMmy_6kernel4sync3arc3ArcINtNtNtNtBN_5block2mq7tag_set6TagSetNtNvNvNvCs8MySzWyGC07_25doctests_kernel_generated33rust_doctest_kernel_block_mq_rs_04main42__doctest_main_rust_kernel_block_mq_rs_58_011MyBlkDeviceEEEB23_>:ffffffff818bb250
>
> Currently, fgets will truncate on the first read of this line (but this
> is fine since we see it starts with '<' and continue the loop), but on
> the second we get "rs_58_011MyBlkDeviceEEEB23_>:ffffffff818bb250", which
> is treated as malformed.
>
> Signed-off-by: Mitchell Levy <levymitchell0@gmail.com>

Thanks Mitchell -- this is:

    https://lore.kernel.org/rust-for-linux/320c4dba-9919-404b-8a26-a8af16be1845@app.fastmail.com/

as well as:

    https://lore.kernel.org/rust-for-linux/20241117195923.222145-1-sergio.collado@gmail.com/

It would be nice to get something like this finally in.

Cheers,
Miguel