This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
MIPS port .MIPS.content sections overzealous
- To: egcs-bugs at egcs dot cygnus dot com
- Subject: MIPS port .MIPS.content sections overzealous
- From: davea at quasar dot engr dot sgi dot com (David B Anderson)
- Date: Fri, 19 Mar 1999 18:03:19 -0800 (PST)
Misinterpretation in gcc:
gcc/egcs with a MIPS target is currently generating
.MIPS.content.debug_* sections for the dwarfv2 .debug_*
sections. And relocation sections for the content sections
in a .o.
This is a mistake, and beginning with the MIPSpro7.3 linker we
will strip such out of an executable or
DSO (dynamic shared object, SYSVRel4 shared library)
automatically (as of this week we changed
the linker). But it's better not to generate such at all...
We realized (after having problems with the gcc-generated
sections) that our ELF64 document (which you likely have seen,
but I am not sure) was inconclusive on this point.
It now says:
---------SGI elf64 document quote (as of this week)
A content section is required for each section used by the executing pro
gram which contains data of other than its default class, as determined by
the section's attribute flags:
SHF_EXECINSTR executable code
SHF_MIPS_ADDR address data of size
implied by section element size
other non-address data
Note that address data refers to storage initialized to relocatable address
es, not to user pointer data which is uninitialized or initialized to NULL.
Note that none of the DWARF sections have associated content sections.
--------end SGI elf64 document quote
details: --------------------------------
The user-visible symptom with a mips-target executable is that
the .debug_info section is marked strippable but
.MIPS.content.debug_info is marked unstrippable by the
linker. SGI strip(1) emits noxious warnings when one strips the
executable (strip is being sensible, given what it sees).
Only stuff in the executable image should have .MIPS.contents.
(text and data, not bss) Currently .debug_frame is not in the image
(but this is arguably a mistake on our part as we defined things
this way) but, regardless if in the image or not .debug_frame
should not have a .MIPS.contents.debug_frame section.
(we rely on Xlate section data to handle pixie(1) and cord(1)
translations in the .debug_* data, not on .MIPS.content.debug_*
sections as .MIPS.content.debug_* simply won't work in
general on debug data. (explaining why is another topic, and
this is too long already))
end details --------------------------------
I must apologize for not submitting any diffs, but
we've not prepared any (or even investigated the necessary
change). Sorry.
If there are any questions feel free to contact me or
bean@sgi.com (Bean Anderson, no relation, but he is my boss :-)
Regards,
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/