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: Ian Lance Taylor <ian at airs dot com>
- To: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Cc: binutils at sources dot redhat dot com
- Date: 08 May 2003 20:39:04 -0700
- Subject: Re: [RFA:] Fix bug with #APP/#NO_APP when using macros.
- References: <200305090109.h4919osD009188@ignucius.se.axis.com>
Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> 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.
It's true that #NO_APP needs to be printed in ASM_FILE_START, but it's
not true that the CRIS target is the only target which does it.
m68k.h does it also. I actually thought that the m68k was the only
target which used #NO_APP, but I see that you used it for the CRIS.
I take your point, though, which is that though targets other than
CRIS and m68k emit #APP/#NO_APP around assembler statements, it is
ineffective and pointless.
> 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.])
Probably nobody builds glibc for the m68k, since m68k Unix systems are
pretty rare these days. Particularly m68k ELF systems.
Ian