Re: Commit: Gas: Add .nop directive.

Re: Commit: Gas: Add .nop directive.

[Michael Morrell]

 Once this is in, I hope this code from gcc/configure can be removed:

# ??? Not all targets support dwarf2 debug_line, even within a version
# of gas. Moreover, we need to emit a valid instruction to trigger any
# info to the output file. So, as supported targets are added to gas 2.11,
# add some instruction here to (also) show we expect this might work.
# ??? Once 2.11 is released, probably need to add first known working
# version to the per-target configury.
case "$cpu_type" in
 aarch64 | alpha | arc | arm | avr | bfin | cris | csky | i386 | m32c | m68k \
 | microblaze | mips | nds32 | nios2 | pa | riscv | rs6000 | score | sparc | spu \
 | tilegx | tilepro | visium | xstormy16 | xtensa)
 insn="nop"
 ;;
 ia64 | s390)
 insn="nop 0"
 ;;
 mmix)
 insn="swym 0"
 ;;
esac

You currently have to update this for every new port to be able to check for dwarf2_debug_line support (even if the port has a "nop" instruction).

 Michael

On Monday, September 14, 2020, 08:27:15 AM PDT, Nick Clifton wrote:
 
Hi Guys,

 I am checking in the attached patch to add a ".nop" directive to the
 assembler. This directive creates a single no-op instruction. It is
 similar to the already existing ".nops" directive, apart from two
 important differences:

 1. It is implemented for all architectures, not just x86.
 2. The instruction it generates counts as a real instruction for the
 purposes of DWARF line number table generation.

 Fact 1 is important as it allows the directive to be used to generate
 architecture neutral test cases containing real instructions.

 Tested with a large variety of different targets.

Cheers
 Nick  

Re: Commit: Gas: Add .nop directive.

[Nick Clifton]

Hi Michael,

>  Once this is in, I hope this code from gcc/configure can be removed:

That would be a nice thing to do, but I am not sure that it will work.  Since
gcc still needs to remain compatible with older versions of the binutils I
think that code will need to remain.

What could happen though is that the test could be taught about the new directive
and if it is supported, use it.  This would mean that future new architectures
would not have to have any code added here, the test should just work.

I am contemplating backporting the patch to the 2.35 branch and then triggering
a 2.35.1 point release.  (Actually there are a few more DWARF-5 patches that need
to go in, and then it might be a good time for a point release).  So in theory
the test in gcc could check for binutils 2.35.1 or later, and if present, just
use the .nop directive, without having to worry about anything target specific.

Cheers
  Nick

2.35.1 (was: Commit: Gas: Add .nop directive.)

[Hans-Peter Nilsson]

On Mon, 14 Sep 2020, Nick Clifton via Binutils wrote:
> I am contemplating backporting the patch to the 2.35 branch and then triggering
> a 2.35.1 point release.

If so, please add a 2.35.1 milestone in bugzilla, so bugs that
will be fixed in 2.35.1 can be marked as such.

brgds, H-P
PS. The new .nop test-case fails for mmix.  It's "swym 0" if you beat me to the fix.

Re: 2.35.1 (was: Commit: Gas: Add .nop directive.)

[Nick Clifton]

Hi Hans-Peter,

> If so, please add a 2.35.1 milestone in bugzilla, so bugs that
> will be fixed in 2.35.1 can be marked as such.

Ok, will do.


> PS. The new .nop test-case fails for mmix.  It's "swym 0" if you beat me to the fix.

It does ?  I do not see any failures in my tests.  Can you tell me how to reproduce the problem ?

Cheers
  Nick

Re: 2.35.1 (was: Commit: Gas: Add .nop directive.)

[Hans-Peter Nilsson]

On Tue, 15 Sep 2020, Nick Clifton wrote:
> > PS. The new .nop test-case fails for mmix.  It's "swym 0" if you beat me to the fix.
>
> It does ?  I do not see any failures in my tests.  Can you tell me how to reproduce the problem ?

On a brief inspection, it seems it's not a trivial overlooked
definition (thanks for caring), but instead some kind of
undefinedwilduninitialized thing.  I get in gas.log, at
4a8f181d196f85ca1, for --target=mmix-knuth-mmixware on a
i686-linux host:

../as-new     -o tmpdir/nop.o /home/hp/binutils/src/gas/testsuite/gas/all/nop.s
Executing on host: sh -c {../as-new     -o tmpdir/nop.o /home/hp/binutils/src/gas/testsuite/gas/all/nop.s 2>&1}  /dev/null dump.tmp (timeout = 300)
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s: Assembler messages:
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s:2: Error: junk at end of line, first unrecognized character valued 0x8
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s:2: Error: unknown opcode: `XXXa'
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s:2: Error: junk at end of line, first unrecognized character valued 0x14
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s:2: Error: junk at end of line, first unrecognized character valued 0x14
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s:3: Error: junk at end of line, first unrecognized character valued 0x14
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s:3: Fatal error: internal: unhandled label
failed with: </home/hp/binutils/src/gas/testsuite/gas/all/nop.s: Assembler messages:
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s:2: Error: junk at end of line, first unrecognized character valued 0x8
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s:2: Error: unknown opcode: `XXXa'
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s:2: Error: junk at end of line, first unrecognized character valued 0x14
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s:2: Error: junk at end of line, first unrecognized character valued 0x14
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s:3: Error: junk at end of line, first unrecognized character valued 0x14
/home/hp/binutils/src/gas/testsuite/gas/all/nop.s:3: Fatal error: internal: unhandled label >, no expected output
FAIL: Generate NOPs in an architecture neutral manner

The three characters marked XXX (which I didn't want to include
verbatim) are 0xbd, 0x14, 0x8.

On another host, x86_64-linux built with -m32, everything is
fine.  Perhaps a valgrind and/or asan run will show (later).

brgds, H-P
PS.  It should be "swym 0", not "set $0,$0".  I'll fix.

Re: 2.35.1 (was: Commit: Gas: Add .nop directive.)

[Nick Clifton]

Hi Hans-Peter,

> On a brief inspection, it seems it's not a trivial overlooked
> definition (thanks for caring), but instead some kind of
> undefinedwilduninitialized thing. 

Ah ha!  Please try the vert latest binutils sources.  I checked 
in a patch today that should fix this.  (The problem is that on
some architectures the md_assemble() function leaves input_line_pointer
pointing to its input parameter.  Since s_nops() passes md_assemble
a string which it frees upon return, ilp ends up pointing into freed memory....

Cheers
  Nick

> PS.  It should be "swym 0", not "set $0,$0".  I'll fix.

Thanks - please do.

Re: Commit: Gas: Add .nop directive.

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

Hi Guys,

  The code to implement the .nop directive calls the md_assemble() function 
  with an allocated string, rather than input_line_pointer.  This is supposed
  to work, but there are some targets that assume that md_assemble()'s 
  argument is input_line_pointer, and that they are free to update it.  Even 
  worse some of them assign input_line_pointer to the string argument and
  leave it there.  So when s_nop() finishes and frees the string pointer,
  input_line_pointer is left pointing at freed memory.

  At first I though that it was just the S12Z port that behaved in this way
  but now I have found that the MN10300 port does too.  There may be others
  as well, since the symptom is hard to trace.  So I am applying the attached
  patch to fix s_nop() so that it explicitly preserves input_line_pointer
  instead.

Cheers
  Nick

gas/ChangeLog
2020-09-15  Nick Clifton  <nickc@redhat.com>

	* read.c (s_nop): Preserve the input_line_pointer around the call
	to md_assemble.
	* config/tc-s12z.c (md_assemble): Revert previous delta.

[-- Attachment #2: gas-nop-directive.patch.2 --]
[-- Type: application/x-troff-man, Size: 1383 bytes --]