This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: GNU as -- selevtively/dynamically disabling macro expansion
- From: nick clifton <nickc at redhat dot com>
- To: Jagged <jagged at arcor dot de>
- Cc: binutils at sourceware dot org
- Date: Fri, 26 Oct 2012 17:01:22 +0100
- Subject: Re: GNU as -- selevtively/dynamically disabling macro expansion
- References: <20121010193026.GB22040@saal-b.jagged.ssl>
Hi Jagged,
Sorry for taking so long to reply to your email. I have been very
busy doing other things for the last few months.
I tried to address the maintainer mentioned in the as info pages as well
as the contributor of the listing capability, as given in the respective
source files.
The maintainer details in the gas documentation are very out of date
(and something that I need to fix). The best place to look for
maintainer information is the file binutils/MAINTAINERS in the binutils
source code.
So, the essence of my question is: where does the code decide whether or not
to actually expand a macro, or (this would be sufficient too) where is it
decided to emit the macro expansion to the listing file?
The code in gas/read.c:read_a_source_file () is responsible for deciding
whether a macro expansion should appear in the listing.
- if I use ".nolist" at the beginning of any one macro to suppress
further listing of its expansion, it does not work;
- if I use ".list" at the end of the respective macro, it does not
reestablish the state as it was before the ".nolist" at the very
beginning of the same macro.
This is not what I call to "maintain an internal counter", as quoted above.
There is a (non-static)
Agreed - this is a bug. The implementation should match the
documentation. if you would like to file a bug report on this (here:
http://sourceware.org/bugzilla) that would help.
Cheers
Nick