public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@airs.com>
To: richard.wisenoecker@gmx.at
Cc: binutils@sourceware.cygnus.com
Subject: Re: linker problem with WinCE exe's
Date: Thu, 01 Jul 1999 00:00:00 -0000	[thread overview]
Message-ID: <19990604175929.8438.qmail@daffy.airs.com> (raw)
In-Reply-To: <37582C57.7F8A3E7B@gmx.at>

   Date: Fri, 04 Jun 1999 21:43:19 +0200
   From: wisi <richard.wisenoecker@gmx.at>

   Actually I have an error in the linker with the "import information"
   section of WinCE exe files.
   This stuff is in the .idata section. This section has subsections as
   .idata$2, .idata$3,...,idata$6. The interesting thing is that symbols
   are reallocated correctly.
   I have just an error when the address of the start of .idata$4 is needed

   (In detail: the error occurs at the .idata section offset 0x0 where the

   address of the beginning of .idata$4 should be and at offset 0x10 where
   the address of .idata$5 should be).
   After reallocation I always found the start address of .idata.
   In the function bfd_perform_relocation (in reloc.c) the variables
   symbol->value and  symbol->section->output_offset are always 0.

   It seems to me, that one of these two values (value or output_offset)
   should hold the offset of the subsection inside the section.
   The problem I have is, that I didn't found the function which is
   responsible for this (I spent already some hours with debugging and
   analyzing the code).

I have no idea what the actual problem is here.  However, I can tell
you how this stuff is supposed to work.

You call .idata$2, etc., subsections, but BFD does not have that
concept.  I would describe .idata$2, etc., as input sections which are
(I believe) placed into an output section named .idata.

There is an input BFD and an output BFD.  Similarly, there is an input
section and an output section.

In bfd_perform_relocation, the following should be true:

symbol->value is the offset of the symbol within the input section.

symbol->section->output_section->vma is the VMA of the output section
symbol->in the output BFD.

symbol->section->output_offset is the offset of the input section
symbol->within the output section.

The linker map file generated by the -M option should show you how and
where the linker puts input sections into output sections.

As a side note, I don't think the i386 PE support should be going
through bfd_perform_relocation.  I believe it should be using
_bfd_coff_generic_relocate_section instead.  See bfd/doc/bfdint.texi
for a partial description of linker relocation handling.

Ian

      reply	other threads:[~1999-07-01  0:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-01  0:00 wisi
1999-07-01  0:00 ` Ian Lance Taylor [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=19990604175929.8438.qmail@daffy.airs.com \
    --to=ian@airs.com \
    --cc=binutils@sourceware.cygnus.com \
    --cc=richard.wisenoecker@gmx.at \
    /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).