Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA03344; Sat, 2 Dec 95 16:07:01 EST
Received: from cygnus.com by MIT.EDU with SMTP
	id AB27391; Sat, 2 Dec 95 16:05:58 EST
Received: from flipper.pvv.unit.no (0@flipper.pvv.unit.no [129.241.210.200]) by cygnus.com (8.6.12/8.6.9) with ESMTP id MAA15037 for <gas2@cygnus.com>; Sat, 2 Dec 1995 12:57:59 -0800
Received: from datter.pvv.unit.no (27959@datter.pvv.unit.no [129.241.210.204]) by flipper.pvv.unit.no (8.6.12/8.6.12) with SMTP id VAA01248 for <gas2@cygnus.com>; Sat, 2 Dec 1995 21:57:52 +0100
From: "Arne H. Juul" <arnej@pvv.unit.no>
Received: by datter.pvv.unit.no ; Sat, 2 Dec 1995 21:57:49 +0100
Date: Sat, 2 Dec 1995 21:57:49 +0100
Message-Id: <9512022057.AA11248@datter.pvv.unit.no>
To: gas2@cygnus.com
Subject: .gas.warning sections

I have been looking at getting warnings from gnu ld when
used on mips-dec-netbsd platform (this is "plain" ELF on
little-endian mips).  This deals with both GCC, the assembler
and the linker, so forgive me if this message is rather long-winded.

So from looking in the GNU libc it looks like this should be
done like in this simple example:

#define link_warning(symbol, msg)                       \
  static const char __evoke_link_warning_##symbol[]     \
    __attribute__ ((section (".gnu.warning." #symbol))) = msg;

link_warning(null1, "This program uses null1(), which is pointless.\n");
int null1(void) {}

At first, this doesn't get through gcc, I just get
"section attributes are not supported for this target".  From
looking at c-common.c this is because ASM_OUTPUT_SECTION_NAME,
which should mean that the target platform doesn't support
arbitrarily named sections.

Now in config/mips the only file defining ASM_OUTPUT_SECTION_NAME
is elf64.h, which has this code in it:

/* A C statement to output something to the assembler file to switch to section
   NAME for object DECL which is either a FUNCTION_DECL, a VAR_DECL or
   NULL_TREE.  Some target formats do not support arbitrary sections.  Do not
   define this macro in such cases.  */

#define ASM_OUTPUT_SECTION_NAME(F, DECL, NAME) \
do {                                                            \
  extern FILE *asm_out_text_file;                               \
  if ((DECL) && TREE_CODE (DECL) == FUNCTION_DECL)              \
    fprintf (asm_out_text_file, "\t.section %s,\"ax\",@progbits\n", (NAME)); \
  else if ((DECL) && TREE_READONLY (DECL))                      \
    fprintf (F, "\t.section %s,\"a\",@progbits\n", (NAME));     \
  else                                                          \
    fprintf (F, "\t.section %s,\"aw\",@progbits\n", (NAME));    \
} while (0)

This is probably really an assembler question:  Is all this stuff really
necessary, and what does the extra @progbits mean?  Stuffing this
code into netbsd.h as well seemed to work ok, but then I looked a bit
further, and while svr4.h has a somewhat simple version of this,
h8300/h8300.h has something more like what I had imagined:
#define ASM_OUTPUT_SECTION_NAME(FILE, DECL, NAME) \
  fprintf (FILE, "\t.section %s\n", NAME)

Stuffing this code into netbsd.h instead seemed to work just as well.
I would welcome enlightenment on this issue. (Maybe it should
be common code in config/mips/something.h?)

Another (maybe somewhat irrelevant) inquiry:  With any of the
two variants above gcc accepts my test file and gas produces an
object file with the required section.  When linking a 'main'-type
file which uses the symbol in question (null1 for my example)
I also get my warning:
tm.o: In function `main':
tm.c(.text+0x28): This program uses null1(), which is pointless.

However, if I change my test file to have *only* the warning section
for null1 (not the function definition itself), I get the following
behaviour:

gcc: Internal compiler error: program ld got fatal signal 6

This is if the program doesn't reference null1() at all.
If I do reference null1() it works right:

tm.o: In function `main':
tm.c(.text+0x28): This program uses null1(), which is pointless.
tm.c(.text+0x28): undefined reference to `null1'

This seems to be a (probably obscure) bug in ld, but hopefully it
shouldn't give me any "real" problems, right?

Yours,
  - Arne H. Juul
