.Ltext0 handling in MIPS back-end

Mark Mitchell mark@codesourcery.com
Tue Jul 20 00:27:00 GMT 1999


On IRIX6, GCC generates something like this at the top of every file:

	.section	.text
  .Ltext0:

The intention is that .Ltext0 be a label, in the text section, for the
first byte of text in the file.  However, the IRIX assembler does not
always cooperate.  Consider this assembly file:

	  .section	.text
  .Ltext0:
	  .section	foo,1,6,16,4
	  .align	3
	  .globl	f
	  .ent	f
  f:	
	  .end	f
	  .section	.data
	  .8byte	.Ltext0

When assembled like this:

> as -64 -o test.o test.s

we get:

  "test.s", line 10: warning(1001): last line of file ends without a newline
	  .8byte	.Ltext0
			 ^

  as: Warning: /test.s, line 2: label should be inside .ent/.end block: .Ltext0
       .Ltext0:

Running `elfdump' on the generated .o yields the following surprising
information:

  test.o:

		   ***** SYMBOL TABLE INFORMATION *****
  [Index]  Value              Size     Type    Bind     Other    Shndx    Name
  [5]	 0x0                0        OBJECT  LOCAL    DEFAULT  6        .Ltext0
	    **** SECTION  HEADER  TABLE ****
  [No]   Type                  Addr               Offset          Size        Nam
  [6]    SHT_PROGBITS          0                  0x3f0           0           foo
	 0          0          0x1                0x10            0x00000006 ALLOC EXECINSTR 

In other words, .Ltext0 is actually in section foo!

This happens with linkonce sections; they take the place of `foo'.
The assembler warning is silenced; gcc uses -w when invoking the
assembler.

When compiling -g we get assembler *errors* because we try to take the
difference between .Letext0 (which does wind up in .text) and .Letext
(which does not).

This bug does not seem to affect the non-GNU-ld configuration because
(by happenstance) we do not generate .text sections other than .text.
However, I suspect we could cobble up something involving static
constructors that triggered the bug.

The only thing I can think of is to create a dummy function in every
translation unit, something like:

    .ent .Ltext0
  .Ltext0:
    .end .Ltext0

fixes the problem.

Would you accept a patch to dwarf2out.c that inserted
machine-dependent hooks for use around the outputting of the various
labels in dwarf2out_init and dwarf2out_finish?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


More information about the Gcc-bugs mailing list