This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [RFA:] Fix bug with #APP/#NO_APP when using macros.
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: ian at airs dot com
- Cc: hans-peter dot nilsson at axis dot com, binutils at sources dot redhat dot com
- Date: Fri, 9 May 2003 03:09:50 +0200
- Subject: Re: [RFA:] Fix bug with #APP/#NO_APP when using macros.
> From: Ian Lance Taylor <ian@airs.com>
> Date: 08 May 2003 14:38:55 -0700
> Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
>
> > An alternative is to remove this support completely and ignore
> > #NO_APP/#APP; always scrub. This is IMHO reasonable, since
> > apparently no other GCC port uses this feature.
>
> There are several gcc ports which currently use #NO_APP. Grep for it
> in gcc/config/*.h.
I assume you mean ASM_APP_ON/OFF, emitted around inline asm. If
so, that's my point and apparently a major misconception: If not
the very first thing in the file, #NO_APP (and #APP) are
ineffective and do not cause scrubbing of the file; strict
formatting is assumed. Any later #APP and #NO_APP are then
actually scrubbed away (for reference .include:d files count as
separate). To make #NO_APP the very first thing in the
GCC-emitted assembly-file, it has to be emitted by the port: it
should define ASM_FILE_START to do so. GCC does not emit
ASM_APP_OFF in the file prologue by itself and hasn't done so in
the single-digit years I can remember. Only cris-* defines
ASM_FILE_START so AFAICT, though some ports emit #NO_APP as the
second or third line(!). For GCC, refer to
toplev.c:init_asm_output. For gas, refer to
input-file.c:input_file_open.
Actually, if you change a port to emit #NO_APP first, you'll
notice for glibc systems that (as I muttered in a previous post)
glibc relies on a kludge based on scrubbing being done. At
least it did last time I was there. (Looking...) it seems it
still does. See include/libc-symbols.h:link_warning: ``Tacking
on "\n\t#" to the section name makes gcc put it's bogus section
attributes on what looks like a comment to the assembler.''
Unfortunately no assembly comments are allowed with #NO_APP
(i.e. scrubbing not done), so you then get assembler syntax
errors. For cris-axis-linux-gnu, glibc for cris-axis-linux-gnu
is compiled with -mpdebug, which is a GCC port-specific
assembly-output debug option with the side-effect of omitting
the first #NO_APP. (For reference, this was in the original
glibc CRIS port submission, which should be in glibc ml archives
around 2001-04-08, but the option was misunderstood for some
reason and was omitted when sysdeps/cris/Makefile was committed,
thus breaking the port. [Hmm, I really should revisit for this
and other reasons. Oh well, I'll schedule that for later this
year.])
> It would be interesting to profile the assembler to see how much time
> would be lost by ignoring #NO_APP. Try assembling the same file
> twice, once with a patched assembler which always scrubs, and compare
> the timings. (I always used to use cccp.c for this sort of test case,
> as a convenient very large source file; it is now gone, alas).
Ok, I'll put it on my TODO list to time a build of a C-only
cris-* newlib-based toolchain with and without such a change.
It should be just as easy as compiling a single file, and C-only
is (still ;-) reasonably fast with GCC that assembly scrubbing
time should be a measurable, at least with that many files.
brgds, H-P