Re: gas: should duplicate .macro directives be allowed?

Re: gas: should duplicate .macro directives be allowed?

[Jan Beulich]

Yes, the change was deliberate, and I don't think it'd be wise to revert
it (it's simply dangerous considering that you might have these
collisions resulting from two include files, each of which relies on
their definition of the respective macro). Instead, if you need to
override a previous macro definition (and know what you're doing), you
can use easily use .purgem before the new definition (really, I'd rather
recommend not to to catch the collision). Jan

>>> Daniel Jacobowitz <drow@false.org> 06.03.05 18:56:05 >>>
My system assembler is binutils 2.15, and allows duplicate macros; the
later
one wins.  GDB's testsuite relies on this; I built a combined tree and
dejagnu decided to use the in-tree assembler for asm-source.exp, which
no
longer allows this.  Thus:

/nevyn/big/fsf/objects/commit-gdb/gdb/testsuite/gdb.asm/arch.inc:
Assembler messages:
/nevyn/big/fsf/objects/commit-gdb/gdb/testsuite/gdb.asm/arch.inc:35:
Error: Macro with this name was already defined

From gdb.asm/common.inc:

comment "arch.inc is responsible for defining the following macros:"
comment "enter - subroutine prologue"
comment "leave - subroutine epilogue"
comment "call - call a named subroutine"
comment "several_nops - execute several (typically 4) nops"
comment "exit0 - exit (0)"

comment "arch.inc may also override the default definitions of:"
comment "datavar - define a data variable"
comment "declare - declare the start of a subroutine"
comment "end - end a subroutine"

Then an architecture-specific file is included, in this case i386.inc.


Was the change deliberate?  If so, it needs to be documented (I'd
prefer to
revert it).  It appears to have come in here:

2005-01-31  Jan Beulich  <jbeulich@novell.com>

        * macro.c (do_formals): Adjust to no longer accept empty
parameter
        names.
        (define_macro): Adjust to no longer accept empty macro name,
garbage
        following the parameters, or macros that were previously
defined.
        * read.c (s_bad_end): Declare.
        (potable): Add endm. Handler for endr and endm is s_bad_end.
        (s_bad_end): Rename from s_bad_endr. Adjust to handle both
.endm
        and .endr.
        * read.h (s_bad_endr): Remove.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gas: should duplicate .macro directives be allowed?

[Ian Lance Taylor]

"Jan Beulich" <JBeulich@novell.com> writes:

> Yes, the change was deliberate, and I don't think it'd be wise to revert
> it (it's simply dangerous considering that you might have these
> collisions resulting from two include files, each of which relies on
> their definition of the respective macro). Instead, if you need to
> override a previous macro definition (and know what you're doing), you
> can use easily use .purgem before the new definition (really, I'd rather
> recommend not to to catch the collision). Jan

That seems more or less reasonable to me, but Daniel is correct that
this change must be mentioned in NEWS.  It should be documented
somewhere in as.texinfo as well, if it is not already.

Ian

Re: gas: should duplicate .macro directives be allowed?

[Daniel Jacobowitz]

On Mon, Mar 07, 2005 at 11:15:02AM -0500, Ian Lance Taylor wrote:
> "Jan Beulich" <JBeulich@novell.com> writes:
> 
> > Yes, the change was deliberate, and I don't think it'd be wise to revert
> > it (it's simply dangerous considering that you might have these
> > collisions resulting from two include files, each of which relies on
> > their definition of the respective macro). Instead, if you need to
> > override a previous macro definition (and know what you're doing), you
> > can use easily use .purgem before the new definition (really, I'd rather
> > recommend not to to catch the collision). Jan
> 
> That seems more or less reasonable to me, but Daniel is correct that
> this change must be mentioned in NEWS.  It should be documented
> somewhere in as.texinfo as well, if it is not already.

While I'm wishing, it would be nice if the documentation mentioned
.purgem somewhere from .macro.  I spent a while trying to figure out if
there was a right way to do this from the manual, and did not come
across .purgem until Jan mentioned it.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gas: should duplicate .macro directives be allowed?

[Erik Christiansen]

On Mon, Mar 07, 2005 at 11:19:17AM -0500, Daniel Jacobowitz wrote:
> On Mon, Mar 07, 2005 at 11:15:02AM -0500, Ian Lance Taylor wrote:
> > "Jan Beulich" <JBeulich@novell.com> writes:
> > 
> > > Yes, the change was deliberate, and I don't think it'd be wise to revert
> > > it (it's simply dangerous considering that you might have these
> > > collisions resulting from two include files, each of which relies on
> > > their definition of the respective macro). Instead, if you need to
> > > override a previous macro definition (and know what you're doing), you
> > > can use easily use .purgem before the new definition (really, I'd rather
> > > recommend not to to catch the collision). Jan
> > 
> > That seems more or less reasonable to me, but Daniel is correct that
> > this change must be mentioned in NEWS.  It should be documented
> > somewhere in as.texinfo as well, if it is not already.
> 
> While I'm wishing, it would be nice if the documentation mentioned
> .purgem somewhere from .macro.  I spent a while trying to figure out if
> there was a right way to do this from the manual, and did not come
> across .purgem until Jan mentioned it.

   Is there merit to issuing a warning on probably inadvertent macro
redefinition? (i.e. Not purged first.) Silent brute-force redefinition
seems very risky, since it depends on fortuitous header include order,
if the preferred macro is to win the invisible contest. Existing code
inadvertently relying on the silent contest would not be broken by a
warning, but the risky programming would be revealed.

   My many macros have not yet collided, but if multiple include files
should ever lead to name conflict, the assembler should warn, because
one macro is in desperate need of renaming or purging, purely through
oversight resulting from increasing complexity.

Many thanks for your tireless efforts.

Erik

gas: should duplicate .macro directives be allowed?

[Daniel Jacobowitz]

My system assembler is binutils 2.15, and allows duplicate macros; the later
one wins.  GDB's testsuite relies on this; I built a combined tree and
dejagnu decided to use the in-tree assembler for asm-source.exp, which no
longer allows this.  Thus:

/nevyn/big/fsf/objects/commit-gdb/gdb/testsuite/gdb.asm/arch.inc: Assembler messages:
/nevyn/big/fsf/objects/commit-gdb/gdb/testsuite/gdb.asm/arch.inc:35: Error: Macro with this name was already defined

From gdb.asm/common.inc:

comment "arch.inc is responsible for defining the following macros:"
comment "enter - subroutine prologue"
comment "leave - subroutine epilogue"
comment "call - call a named subroutine"
comment "several_nops - execute several (typically 4) nops"
comment "exit0 - exit (0)"

comment "arch.inc may also override the default definitions of:"
comment "datavar - define a data variable"
comment "declare - declare the start of a subroutine"
comment "end - end a subroutine"

Then an architecture-specific file is included, in this case i386.inc.


Was the change deliberate?  If so, it needs to be documented (I'd prefer to
revert it).  It appears to have come in here:

2005-01-31  Jan Beulich  <jbeulich@novell.com>

        * macro.c (do_formals): Adjust to no longer accept empty parameter
        names.
        (define_macro): Adjust to no longer accept empty macro name, garbage
        following the parameters, or macros that were previously defined.
        * read.c (s_bad_end): Declare.
        (potable): Add endm. Handler for endr and endm is s_bad_end.
        (s_bad_end): Rename from s_bad_endr. Adjust to handle both .endm
        and .endr.
        * read.h (s_bad_endr): Remove.


-- 
Daniel Jacobowitz
CodeSourcery, LLC