From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: "Boehm, Hans" Cc: "'gdb@sources.redhat.com'" Subject: Re: FW: [ia64-tools] Gdb error message Date: Tue, 27 Feb 2001 18:37:00 -0000 Message-id: References: <140D21516EC2D3119EE7009027876644049B5C3E@hplex1.hpl.hp.com> X-SW-Source: 2001-02/msg00427.html "Boehm, Hans" writes: > Kevin Buettner suggested I repeat this question here. > > This is on an Itanium machine running a recent Red Hat installation. Can > anyone interpret the error message: > > internal error - unimplemented function unk_lang_create_fundamental_type > called. Yes. It can't determine the language of the source files, from the debug info (likely, the debug info is in error), and because the debug info says it has a language, and it's blah, and it has no clue what blah is, .... > > or suggest a plausible workaround? > > Thanks. > > Hans > > -----Original Message----- > From: Boehm, Hans [ mailto:hans_boehm@hp.com ] > Sent: Tuesday, February 27, 2001 10:58 AM > To: hboehm@napali.hpl.hp.com > Subject: [ia64-tools] Gdb error message > > > I'm trying to debug some miscompiled executables generated by gcj. I'm > using gdb 5.0 from an rpm package gdb-5.0-7. The executable is statically > linked, but multithreaded. > > I seem to have gotten into a rut where almost anything results in the error > message: > > internal error - unimplemented function unk_lang_create_fundamental_type > called. > > This is after a few other errors on process startup: > > warning: unable to set global thread event mask > > rw_common (): write: No such file or directory. > > warning: stop_or_attach_thread: generic error > > Can anyone interpret this? This seems like unfriendly behavior from gdb, > even if it's being fed garbage. Is there a fixed version of gdb? (I don't > know how correct or incorreect the gcj-generated debug information is. I > recall seeing the process startup errors also with statically linked C code. > The behavior is the same whether I compile with -g or not. It's different > on a stripped executable, but unsurprisingly that doesn't get far either.) > > Thanks. > > Hans