Re: Add ARM to gas .file/.loc tests

[Richard Earnshaw <rearnsha at arm dot com>]

> On Sat, 23 Nov 2002, Hans-Peter Nilsson wrote:
> > On Sat, 23 Nov 2002, Richard Earnshaw wrote:
> > > > On Fri, 22 Nov 2002, Daniel Jacobowitz wrote:
> >
> >   I (H-P) wrote:
> > > > I think it'd be better to use ".long 0" universally.  Then the
> > > > target-dependent insn=some-nop settings can go.
> >
> > > .long 0 is not a recognized nop on the ARM (it doesn't do very much, but
> > > it isn't strictly a nop).  So what do we want?  A nop? or a zero?
> >
> > Something that fills code-space so the dwarf2 line number
> > indicators move.  It doesn't matter what it does in terms of
> > being an instruction.
> >
> > Oh wait, then it doesn't trig the tc-*.c code or indicate the
> > absence of it.
> 
> (Arguing with myself after checking:) But that's not what is
> tested; it's that ".file" and ".loc"  directives don't cause
> errors!  So ".long 0" should be as fine for this test, as it is
> for various binutils tests.
> 
> brgds, H-P
> 

Ok, let me check that I've understood precisely what this 'nop' is for...  
It's only used by configure while trying to test for the presence of .file 
and .loc support in the assembler.  That is, after this point we don't use 
the nop at all (ie we don't start putting extra nops into gcc-compiled 
code as a result of this change).

I was initially under the impression that we were generating extra nop 
instructions into the compiled code -- where using the correct nop is 
essential.  If this is only for an assembler test, then I see no reason 
why .long shouldn't be used (or maybe .byte 0,0,0,0 if alignment might be 
an issue).

R.