ADV: Top Search Engine Placement

[mike23]

Removal instructions below.

I saw your listing on the internet.

I work for a company that specializes
in getting clients web sites listed
as close to the top of the major 
search engines as possible.

Our fee is only $29.95 per month to
submit your site at least twice a
month to over 350 search engines 
and directories.

To get started and put your web site
in the fast lane, call our toll free
number below.


Mike Bender
888-532-8842


To be removed call: 888-800-6339 X1377




From address@hidden Sun Jun 03 14:16:51 2001
Received: from sprettur.isnet.is ([193.4.58.19])
        by fencepost.gnu.org with esmtp (Exim 3.16 #1 (Debian))
        id 156cQj-0005NR-00
        for <address@hidden>; Sun, 03 Jun 2001 14:16:50 -0400
Received: from nntp1.ba.best.com (nntp1.ba.best.com [206.184.139.132])
        by sprettur.isnet.is (8.11.1/8.11.0/isnet) with ESMTP id f53IGLT63911
        for <address@hidden>; Sun, 3 Jun 2001 18:16:21 GMT
        (envelope-from address@hidden)
Received: (from address@hidden)
        by nntp1.ba.best.com (8.11.3/8.11.3) id f53IGEP53376
        for address@hidden; Sun, 3 Jun 2001 11:16:14 -0700 (PDT)
        (envelope-from news)
To: address@hidden
Path: baz.don-lindsay-archive.org!not-for-mail
From: address@hidden (Don Lindsay)
Newsgroups: gnu.utils.bug
Subject: need ld fix in assign_file_positions_for_segments
Date: Sun, 3 Jun 2001 18:17:37 +0000 (UTC)
Organization: lots
Lines: 62
Message-ID: <address@hidden>
Reply-To: address@hidden
NNTP-Posting-Host: dynamic21.pm15.san-jose.best.com
X-Trace: nntp1.ba.best.com 991592173 53374 209.157.114.149 (3 Jun 2001 18:16:13 
GMT)
X-Complaints-To: address@hidden
NNTP-Posting-Date: Sun, 3 Jun 2001 18:16:13 +0000 (UTC)
Summary: wild offset based on sec->vma
Sender: address@hidden
Errors-To: address@hidden
X-BeenThere: address@hidden
X-Mailman-Version: 2.0.3
Precedence: bulk
List-Help: <mailto:address@hidden>
List-Post: <mailto:address@hidden>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/bug-gnu-utils>,
        <mailto:address@hidden>
List-Id: Bug reports for the GNU utilities <bug-gnu-utils.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/bug-gnu-utils>,
        <mailto:address@hidden>
List-Archive: <http://mail.gnu.org/pipermail/bug-gnu-utils/>

I have an ld bug which causes

        _bfd_elf_assign_file_position_for_section

in bfd/elf.c to be called with a big negative value for 

        file_ptr offset;

This is eventually passed to an fseek, which of course fails.
The error message is about a truncated file.

I've tracked the silly offset to this call chain:

              assign_file_positions_for_segments
             assign_file_positions_except_relocs
            _bfd_elf_compute_section_file_positions
           bfd_elf32_bfd_final_link
          _bfd_elf32_gc_common_final_link
         ldwrite
        main

        (My problem is in the first call to assign_file_positions_for_segments.
        There's a comment in bfd_elf32_bfd_final_link about how the 
        _bfd_elf_compute_section_file_positions call has to be done
        twice, since it gets something wrong the first time. My
        test case never gets to the second call.)

and the offending code in elf.c assign_file_positions_for_segments is this:

          /* The section may have artificial alignment forced by a
             link script.  Notice this case by the gap between the
             cumulative phdr vma and the section's vma.  */
          if (p->p_vaddr + p->p_memsz < sec->vma)
            {
              bfd_vma adjust = sec->vma - (p->p_vaddr + p->p_memsz);

              p->p_memsz += adjust;
 --->         off += adjust;
              voff += adjust;
              if ((flags & SEC_LOAD) != 0)
                p->p_filesz += adjust;
            }

The trouble being that sec->vma is 0xf0000000. (I have a fancy link
script: the code is for an embedded CPU.) So, "adjust" becomes huge
(and negative). Obviously fseek's into the output file shouldn't
be linear in sec->vma.

I used GDB to pretend that the "off += adjust;" line wasn't there,
and my test case ran to completion. So I'm sure I need a fix 'round
about here.

(I'm using a 2.10 binutils source from about February: the 1june snapshot
has no changes that look relevant.)

I'd really appreciate input about this. I'd be happy to post a test case.

Thanks,
Don
-- 
Don
Donald C. Lindsay   www.don-lindsay-archive.org