https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #1 from rguenther at suse dot de <rguenther at suse dot de> --- [...] >>collect2: fatal error: ld terminated with signal 11 [Segmentation >>Fault] >>compilation terminated. >>ld: warning: file /var/tmp//ccOFDEXadebugobjtem: section [1] has >>invalid type [ >>SHT_NULL ] >>ld: warning: file /var/tmp//ccOFDEXadebugobjtem: section [5] contains >>both >>SHF_EXCLUDE and SHF_ALLOC flags: SHF_EXCLUDE ignored [...] >>Clearly a SEGV isn't the best error handling, and I'm not yet certain >>if the >>errors >>are benign. OTOH, I don't yet know why the objects are created this >>way. > > They are created that way to make my life easier. They are supposed to be > valid > ELF objects and they are according to the specs and my interpretation. My reading is different and corroborates the Solaris ld warnings: * for SHT_NULL, the ELF gABI 4.1 is pretty explicit: p. 4-13, p.57: SHT_NULL This value marks the section header as inactive; it does not have an associated section. Other members of the section header have undefined values. * SHF_EXCLUDE is a later addition, also included in the Solaris Linker and Libraries Guide: http://docs.oracle.com/cd/E53394_01/html/E54813/chapter6-94076.html#OSLLGchapter6-10675 SHF_EXCLUDE This section is excluded from input to the link-edit of an executable or shared object. This flag is ignored if the SHF_ALLOC flag is also set, or if relocations exist against the section. This is identical to the wording in the binutils PR which introduced this flag: PR gas/11600: Support SHF_EXCLUDE https://sourceware.org/bugzilla/show_bug.cgi?id=11600 Seems far from clear to me that those are valid ELF objects: the warnings seem totally appropriate. Rainer
