This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]