This is the mail archive of the
mailing list for the GDB project.
Re: TI C6x support
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Stephen Biggs <xyzzy at hotpop dot com>
- Cc: GDB list <gdb at sources dot redhat dot com>
- Date: Mon, 22 Sep 2003 00:54:52 -0400
- Subject: Re: TI C6x support
- References: <firstname.lastname@example.org> <email@example.com>
May I ask why nobody has answered me?
Very likely, and unfortunatly, because no one here uses COFF.
On Sun, 2003-08-31 at 11:21, Stephen Biggs wrote:
I am adding full support for the TI C6X (mostly C64xx) chip to BFD and
GDB. I intend to submit a patch as soon as stability of my port and
company politics allow.
I am stuck.
It seems that the COFF version of GDB creates a fake symbol table with a
filename of "_globals_" and <unknown> language. This is not working for
me. I compile with Dwarf2 and have all the symbols and the symbols show
up in a dump as correct for the C file. When I try to "disassemble
main", I get back the response "main is not a function". This is the
same response I get when I try "list". Disassembly using the raw
address of "main" works just fine.
I am trying to decipher the code that causes these messages but am
running into a wall. I know that this is something stupid on my part
and quite simple, but I just can't get it.
It's probably a bug. I suspect you either have corrupt input, or GDB is
getting out of sync. I've quoted some relevant sections of the
out-of-print book Understanding and Using COFF:
``Index 0, for .file, is an N_DEBUG section number. Though in general
N_DEBUB means value is meaningless, in the case of .file, the value has
a very important meaning. Value is the symbol table index to the next
.file symbol table entry. The .file symbol table value entries form a
linked circular list (the filan entry points back to the first) that is
used by the debugger to quickly find the region of debug information
associated with the particular .file filename.''
``Defined global symbol table entries follow the static symbol table
entries of the last filename-function-static symbol table sequence.''
``Undefined global symbol are the last entries in the symbol table.
This is true only for an object file: an executable file does not hae
any undefined references. It wouldn't be executable if it did.''
The code appears to think that its fallen off the end of the symbol
table and into the globals section.