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.


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


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