From: "Jan Beulich" <JBeulich@novell.com>
To: <drow@false.org>,<binutils@sources.redhat.com>
Cc: <gdb@sources.redhat.com>
Subject: Re: gas: should duplicate .macro directives be allowed?
Date: Mon, 07 Mar 2005 07:36:00 -0000 [thread overview]
Message-ID: <s22c045e.046@emea1-mh.id2.novell.com> (raw)
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
next reply other threads:[~2005-03-07 7:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-07 7:36 Jan Beulich [this message]
2005-03-07 16:15 ` Ian Lance Taylor
2005-03-07 16:20 ` Daniel Jacobowitz
2005-03-08 1:02 ` Erik Christiansen
-- strict thread matches above, loose matches on Subject: below --
2005-03-06 17:56 Daniel Jacobowitz
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=s22c045e.046@emea1-mh.id2.novell.com \
--to=jbeulich@novell.com \
--cc=binutils@sources.redhat.com \
--cc=drow@false.org \
--cc=gdb@sources.redhat.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