This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


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

MIPS port .MIPS.content sections overzealous



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/


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