From: Jan Beulich <jbeulich@suse.com>
To: Binutils <binutils@sourceware.org>
Cc: "H.J. Lu" <hjl.tools@gmail.com>
Subject: [PATCH 11/11] gas: make .nops output visible in listing
Date: Wed, 27 Sep 2023 17:53:16 +0200 [thread overview]
Message-ID: <8e35142f-eb0f-7308-e241-407e136390c8@suse.com> (raw)
In-Reply-To: <7ce54bc2-fef2-d2e4-21fd-202fdead0c20@suse.com>
Due to using a different frag type (in turn due to storing data
differently), making the resulting code appear in listings requires
special handling.
--- a/gas/as.h
+++ b/gas/as.h
@@ -247,7 +247,9 @@ enum _relax_state
1 constant byte: no-op fill control byte. */
rs_space_nop,
- /* Similar to rs_fill. It is used to implement .nop directive . */
+ /* Similar to rs_fill. It is used to implement .nops directive.
+ When listings are enabled, fr_opcode gets the buffer assigned, once
+ that's available. */
rs_fill_nop,
/* A DWARF leb128 value; only ELF uses this. The subtype is 0 for
--- a/gas/listing.c
+++ b/gas/listing.c
@@ -815,6 +815,28 @@ calc_hex (list_info_type *list)
var_rep_idx = var_rep_max;
}
}
+ else if (frag_ptr->fr_type == rs_fill_nop && frag_ptr->fr_opcode)
+ {
+ gas_assert (!octet_in_frag);
+
+ /* Print as many bytes from fr_opcode as is sensible. */
+ while (octet_in_frag < (unsigned int) frag_ptr->fr_offset
+ && data_buffer_size < MAX_BYTES - 3)
+ {
+ if (address == ~(unsigned int) 0)
+ address = frag_ptr->fr_address / OCTETS_PER_BYTE;
+
+ sprintf (data_buffer + data_buffer_size,
+ "%02X",
+ frag_ptr->fr_opcode[octet_in_frag] & 0xff);
+ data_buffer_size += 2;
+
+ octet_in_frag++;
+ }
+
+ free (frag_ptr->fr_opcode);
+ frag_ptr->fr_opcode = NULL;
+ }
frag_ptr = frag_ptr->fr_next;
}
--- a/gas/write.c
+++ b/gas/write.c
@@ -1682,7 +1682,12 @@ write_contents (bfd *abfd ATTRIBUTE_UNUS
bfd_get_filename (stdoutput),
bfd_errmsg (bfd_get_error ()));
offset += count;
- free (buf);
+#ifndef NO_LISTING
+ if (listing & LISTING_LISTING)
+ f->fr_opcode = buf;
+ else
+#endif
+ free (buf);
}
continue;
}
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -598,6 +598,7 @@ if [gas_32_check] then {
run_list_test "inval-pseudo" "-al"
run_dump_test "nop-1"
run_dump_test "nop-1-suffix"
+ run_list_test "nop-1" "-aln"
run_dump_test "nop-2"
run_dump_test "optimize-1"
run_dump_test "optimize-1a"
--- /dev/null
+++ b/gas/testsuite/gas/i386/nop-1.l
@@ -0,0 +1,39 @@
+[ ]*[0-9]+[ ]+\.text
+[ ]*[0-9]+[ ]+single:
+[ ]*[0-9]+[ ]+\.nops 0
+[ ]*[0-9]+[ ]+.... 90[ ]+nop
+[ ]*[0-9]+[ ]*
+[ ]*[0-9]+[ ]+pseudo_1:
+[ ]*[0-9]+[ ]+.... 90[ ]+\.nops 1
+[ ]*[0-9]+[ ]*
+[ ]*[0-9]+[ ]+pseudo_8:
+[ ]*[0-9]+[ ]+.... 2E8DB426[ ]+\.nops 8
+[ ]*[0-9]+[ ]+00000000 *
+[ ]*[0-9]+[ ]*
+[ ]*[0-9]+[ ]+pseudo_8_4:
+[ ]*[0-9]+[ ]+.... 8D742600[ ]+\.nops 8, 4
+[ ]*[0-9]+[ ]+8D742600 *
+[ ]*[0-9]+[ ]*
+[ ]*[0-9]+[ ]+pseudo_20:
+[ ]*[0-9]+[ ]+.... 2E8DB426[ ]+\.nops 20
+[ ]*[0-9]+[ ]+00000000 *
+[ ]*[0-9]+[ ]+2E8DB426 *
+[ ]*[0-9]+[ ]+00000000 *
+[ ]*[0-9]+[ ]+8D742600 *
+[ ]*[0-9]+[ ]*
+[ ]*[0-9]+[ ]+pseudo_30:
+[ ]*[0-9]+[ ]+.... EB1C2E8D[ ]+\.nops 30
+[ ]*[0-9]+[ ]+B4260000 *
+[ ]*[0-9]+[ ]+00002E8D *
+[ ]*[0-9]+[ ]+B4260000 *
+[ ]*[0-9]+[ ]+00002E8D *
+[ ]*[0-9]+[ ]*
+[ ]*[0-9]+[ ]+pseudo_129:
+[ ]*[0-9]+[ ]+.... EB7F2E8D[ ]+\.nops 129
+[ ]*[0-9]+[ ]+B4260000 *
+[ ]*[0-9]+[ ]+00002E8D *
+[ ]*[0-9]+[ ]+B4260000 *
+[ ]*[0-9]+[ ]+00002E8D *
+[ ]*[0-9]+[ ]*
+[ ]*[0-9]+[ ]+end:
+#pass
next prev parent reply other threads:[~2023-09-27 15:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 15:46 [PATCH 00/11] x86: NOP emission adjustments Jan Beulich
2023-09-27 15:47 ` [PATCH 01/11] x86: record flag_code in tc_frag_data Jan Beulich
2023-09-27 15:48 ` [PATCH 02/11] x86: i386_generate_nops() may not derive decisions from global variables Jan Beulich
2023-09-27 15:48 ` [PATCH 03/11] x86: don't use 32-bit LEA as NOP surrogate in 64-bit code Jan Beulich
2023-09-27 15:49 ` [PATCH 04/11] x86: don't use operand size override with NOP in 16-bit code Jan Beulich
2023-09-27 15:50 ` [PATCH 05/11] x86: respect ".arch nonop" when selecting which NOPs to emit Jan Beulich
2023-09-27 15:50 ` [PATCH 06/11] x86: i686 != PentiumPro Jan Beulich
2023-09-27 15:51 ` [PATCH 07/11] x86: don't record full i386_cpu_flags in struct i386_tc_frag_data Jan Beulich
2023-09-27 15:51 ` [PATCH 08/11] x86: add a few more NOP patterns Jan Beulich
2023-09-27 15:52 ` [PATCH 09/11] x86: fold a few of the "alternative" " Jan Beulich
2023-09-27 15:52 ` [PATCH 10/11] x86: fold NOP testcase expectations where possible Jan Beulich
2023-09-27 15:53 ` Jan Beulich [this message]
2023-09-27 15:59 ` [PATCH 00/11] x86: NOP emission adjustments Jan Beulich
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=8e35142f-eb0f-7308-e241-407e136390c8@suse.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=hjl.tools@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).