Until location views (in gcc-8), there apparently was no need to
emit single bytes of data as anything but bare CONST_INTs,
neither actual data nor dwarf2 debug. With location views,
there's a field within dwarf2 records for inlined subroutines
that as assembly code looks as follows in context (cutout of
assembly output with -dA for the failing libgcc/unwind-c.c):
.uleb128 0x1c !# (DIE (0x3b1) DW_TAG_inlined_subroutine)
.4byte 0x95e !# DW_AT_abstract_origin
.8byte LBI:49 !# DW_AT_entry_pc
.byte LVU:281
!# DW_AT_GNU_entry_view
.4byte Ldebug_ranges:0+0x50 !# DW_AT_ranges
BYTE 2
!# DW_AT_call_file (/home/hp/x/libgcc/unwind-c.c)
BYTE 200
!# DW_AT_call_line
BYTE 11
!# DW_AT_call_column
.4byte 0x489 !# DW_AT_sibling
Note the ".byte LVU:281". The value of LVU:281 is (IIUC) set in a
preceding line that says
.loc 1 279 1 view LVU:281
so it's defined at the time it's used; no relocs or second-pass fixups
needed in the assembler. The preferable "BYTE" pseudodirective
(preferable because it's the same pseudo as "mmixal"), handles only
literal values. There may supposedly exist other assemblers with
similar issues, but I guess we'd have heard from them by now.
This is the second patch of two needed to bring back
mmix-knuth-mmixware to a buildable state. I'll backport both to
gcc-8.
Still, I see lots of test-suite failures, both due to LTO
problems (linking ELF input to mmo format, with non-code
non-data wrapped, but being mishandled by the linker) and to
what appears to be another binutils-bug, so no test-results will
be posted until I can trim the FAILs down to a level where the
sheer volume does not get rejected by the gcc-testresults
mailing list; say to the level of the cris-elf results recently
posted there.
gcc:
PR target/85666
* config/mmix/mmix.c (mmix_assemble_integer): Handle byte-size
non-CONST_INT rtx:es using assemble_integer_with_op ".byte".
Index: gcc/config/mmix/mmix.c
===================================================================
--- gcc/config/mmix/mmix.c (revision 264163)
+++ gcc/config/mmix/mmix.c (working copy)
@@ -1373,8 +1373,14 @@
case 1:
if (GET_CODE (x) != CONST_INT)
{
- aligned_p = 0;
- break;
+ /* There is no "unaligned byte" op or generic function to
+ which we can punt, so we have to handle this here. As
+ the expression isn't a plain literal, the generated
+ assembly-code can't be mmixal-equivalent (i.e. "BYTE"
+ won't work) and thus it's ok to emit the default op
+ ".byte". */
+ assemble_integer_with_op ("\t.byte\t", x);
+ return true;
}
fputs ("\tBYTE\t", asm_out_file);
mmix_print_operand (asm_out_file, x, 'B');
brgds, H-P
