This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: FW: [ia64-tools] Gdb error message
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: Re: FW: [ia64-tools] Gdb error message
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: 27 Feb 2001 21:37:33 -0500
- Cc: "'gdb at sources dot redhat dot com'" <gdb at sources dot redhat dot com>
- References: <140D21516EC2D3119EE7009027876644049B5C3E@hplex1.hpl.hp.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