Re: FW: [ia64-tools] Gdb error message

[Daniel Berlin <dberlin@redhat.com>]

"Boehm, Hans" <hans_boehm@hp.com> 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