.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