public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb@sources.redhat.com, binutils@sources.redhat.com, nickc@redhat.com
Subject: Re: gdb.mi/mi-cli.exp failures
Date: Wed, 02 Apr 2003 18:05:00 -0000	[thread overview]
Message-ID: <20030402180505.GA29974@nevyn.them.org> (raw)
In-Reply-To: <m3istw94m0.fsf@gossamer.airs.com>

On Wed, Apr 02, 2003 at 09:44:07AM -0800, Ian Lance Taylor wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > Well, do you have another suggestion for how to approach this?  We're
> > not actually linking; but I need to get the symbols from the input file
> > into a symbol table with forged offsets in order to apply relocations
> > against them.
> 
> Well, I don't really know the context.  If you're not linking, then it
> seems to me that you'll be better off avoiding the linking calls.  The
> add_symbols() call is the first phase of a link, and is expected to be
> followed by the second phase of a link; despite the name
> add_symbols(), it doesn't just add symbols to a hash table.
> 
> If you really just want to put the symbols into a hash table, can you
> just get the symbol table generically and add them to a hash table
> yourself?

IIRC, then we may get a different kind of hash table than the
platform's relocation application functions expect.  It's been a little
while though.

The context is in bfd/simple.c if you want to look at it.  The
intention is to use this code for both gdb and objdump (they do use it
now, to be more accurate) to relocate the contents of debug sections.
This is necessary for the general cases of debugging shared objects and
unlinked object modules.

> > > Well, I'm afraid that you will have to deal with a number of other
> > > cases if you want to avoid adding sections to input files.  Take a
> > > look at elf_link_create_dynamic_sections().
> > 
> > In any case I can remove the assumption; it's not hard.  I assume that
> > if I save pointers to the sections present before calling
> > elf_link_add_object_symbols, that they'll still be valid when it
> > returns?
> 
> Probably.  But I personally don't think the add_symbols() routine
> needs to make any guarantees at all, except that if you hook up and
> the sections and call final_link() you will get a linked output file.
> Maybe we should change the name add_symbols() to initial_link().
> 
> Ian
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

  reply	other threads:[~2003-04-02 18:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-31 19:35 David Carlton
2003-03-31 20:22 ` Andrew Cagney
2003-03-31 21:08   ` Andrew Cagney
2003-03-31 21:20     ` Andrew Cagney
2003-04-01  1:09       ` Hans-Peter Nilsson
2003-04-01  1:38         ` Ian Lance Taylor
2003-04-01 10:18     ` Nick Clifton
2003-04-01 15:08       ` Andrew Cagney
2003-04-01 15:18         ` Daniel Jacobowitz
2003-04-01 16:22           ` Andrew Cagney
2003-04-01 16:34             ` Daniel Jacobowitz
2003-04-01 17:01               ` Andrew Cagney
2003-04-01 18:03                 ` Daniel Jacobowitz
     [not found]         ` <m31y0mxk8i.fsf@workshop.nickc.cambridge.redhat.com>
2003-04-01 17:09           ` Andrew Cagney
2003-04-01 18:23             ` Daniel Jacobowitz
2003-04-02 17:06               ` Nick Clifton
2003-04-02 17:13                 ` Daniel Jacobowitz
2003-04-02 17:21                 ` Ian Lance Taylor
2003-04-02 17:28                   ` Daniel Jacobowitz
2003-04-02 17:44                     ` Ian Lance Taylor
2003-04-02 18:05                       ` Daniel Jacobowitz [this message]
2003-04-02 20:39                         ` Ian Lance Taylor
2003-04-02 20:38                           ` Daniel Jacobowitz
2003-04-02 20:53                             ` Ian Lance Taylor

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=20030402180505.GA29974@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=binutils@sources.redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=nickc@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).