Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: Stephen Biggs <xyzzy@hotpop.com>
Cc: GDB list <gdb@sources.redhat.com>
Subject: Re: TI C6x support
Date: Mon, 22 Sep 2003 04:55:00 -0000	[thread overview]
Message-ID: <3F6E809C.90007@redhat.com> (raw)
In-Reply-To: <1063180555.31842.0.camel@steve.softier.local>

> 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.

Andrew



      reply	other threads:[~2003-09-22  4:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-31  8:21 Stephen Biggs
2003-09-10  7:56 ` Stephen Biggs
2003-09-22  4:55   ` Andrew Cagney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F6E809C.90007@redhat.com \
    --to=ac131313@redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=xyzzy@hotpop.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox