[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Compiler problem related to dwarf debug info?
I'm doing UPDATE-style rebuilds of NetBSD-current on two of my i386
hosts. One runs netbsd-3 code, the other netbsd-5 code.
On the latter I've seen for a fairly long time that all the powerpc
ports fail to compile sbin/ifconfig/af_atalk.c; the cc1 component of
the compiler errors out with a segmentation fault.
I've dug down to this occurring at this spot:
/* Get the scope die for decl context. Use comp_unit_die for global module
or decl. If die is not found for non globals, force new die. */
scope_die = comp_unit_die;
else if (TYPE_P (context)) <--------
scope_die = force_type_die (context);
scope_die = force_decl_die (context);
inside dwarf2out_imported_module_or_decl() in dwarf2out.c. Expanding
the macro via gcc's tree.h reveals
(TREE_CODE_CLASS (TREE_CODE (CODE)) == tcc_type)
#define TREE_CODE(NODE) ((enum tree_code) (NODE)->common.code)
#define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)]
and the error occurs on this instruction (indexing the tree_code_type
while %eax is 0xbb79d8bf according to my debugger session, which would
of course put the index wide off the mark, unsurprisingly leading to
the segmentation fault.
Commenting out the CFLAGS+=-g setting in sbin/ifconfig/Makefile makes
this symptom go away, since the above function starts out with this
if (debug_info_level <= DINFO_LEVEL_TERSE)
Also, using a cross-compiler built on netbsd-3 works (but this host is
presently hung during reboot requiring operator assistance, and I'm
not where it is, so it's unavailable for comparison at the moment).
I'm wondering if anyone else is seeing this problem, or whether it's
just me and this particular host and setup... So, to repeat the
NetBSD 5.0_BETA host, running NetBSD/i386
Cross-building for any powerpc target (e.g. macppc)
Cross-compiler bombs trying to compile sbin/ifconfig
My host compiler is
gcc version 4.1.3 20080704 prerelease (NetBSD nb1 20080202)
Yes, I realize it's not nb2, but as far as I can see, the only fix
between nb1 and nb2 was a patch for the m68k backend.
Main Index |
Thread Index |