This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: copy_private_bfd_data in bfd/elf.c question
- From: Reva Cuthbertson <reva at cup dot hp dot com>
- To: schwab at suse dot de
- Cc: amodra at bigpond dot net dot au, sje at cup dot hp dot com,binutils at sources dot redhat dot com, reva at cup dot hp dot com
- Date: Fri, 28 Jun 2002 16:06:11 -0700
- Subject: Re: copy_private_bfd_data in bfd/elf.c question
- Organization: Hewlett-Packard Co.
Hello,
In response to Andreas' e-mail, I took a longer look at this and
I believe that I know why we are changing the offset of the .hash
section. Before I get into specifics, I used a different program
than Steve did in his original mail. To illustrate my point, I'm
going to send the readelf output on my test program:
The readelf output for the first 4 sections of the original program
is:
[Nr] Name Type Addr Off Size ES Flg Lk
Inf Al
[ 0] NULL 00000000 ffffffff 000000
00 0 0 0
[ 1] .dynamic DYNAMIC 04000178 000178 0000b8 08 A
0 0 8
[ 2] .dynsym DYNSYM 04000230 000230 0001a0 10 A
3 0 8
[ 3] .dynstr STRTAB 040003d0 0003d0 00029d 00 A
0 0 1
[ 4] .hash HASH 04000670 000670 0000a4 00 A
0 0 8
On th stripped program, the readelf output is:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .dynamic DYNAMIC 04000178 000178 0000b8 08 A
3 0 8
[ 2] .dynsym DYNSYM 04000230 000230 0001a0 10 A
3 0 8
[ 3] .dynstr STRTAB 040003d0 0003d0 00029d 00 A
0 0 1
[ 4] .hash HASH 04000670 00066d 0000a4 04 A
2 0 8
The calculation for section file positions (offsets) happens in:
assign_file_positions_for_segments() in bfd/elf.c:
for (i = 0, secpp = m->sections; i < m->count; i++, secpp++)
{
asection *sec;
flagword flags;
bfd_size_type align;
sec = *secpp;
flags = sec->flags;
align = 1 << bfd_get_section_alignment (abfd, sec);
.
.
.
if (p->p_type == PT_LOAD)
{
bfd_signed_vma adjust;
if ((flags & SEC_LOAD) != 0)
{
adjust = sec->lma - (p->p_paddr + p->p_memsz);
if (adjust < 0)
adjust = 0;
}
adjust gets set to a negative value so it ends up as 0. Because it
it is zero, we just end up using the size of the .dynstr section plus
where .dynstr starts to figure out the file position for .hash. I
believe
that adjust should not be set to a negative value. That seems to
be happening because the segment's paddr field which the HP Linker
sets to 0 is recalculated in code in copy_private_bfd_data()in elf.c
which seems specific to the Solaris linker:
/* The Solaris native linker always sets p_paddr to 0.
We try to catch that case here, and set it to the
correct value. */
if (segment->p_paddr == 0
&& segment->p_vaddr != 0
&& isec == 0
&& output_section->lma != 0
&& (output_section->vma == (segment->p_vaddr
+ (map->includes_filehdr
? iehdr->e_ehsize
: 0)
+ (map->includes_phdrs
? (iehdr->e_phnum
* iehdr->e_phentsize)
: 0))))
map->p_paddr = segment->p_vaddr;
If we didn't mess with p_paddr and left it at 0, in
assign_file_positions_for_segments(), adjust would be
set to 3 and when added to the caculated file position
in that code, the file position for the .hash section would
be 0x670 and not 0x66d which is what we want.
A fix that we came up with is to disable the code
that sets p_paddr in copy_private_bfd_data(). We did
this and it worked fine. The other thing I noticed
is that the alignment specification for .hash is 8.
We never check this value when calculating file
position because that is only done of the section's
flags include SEC_ALLOC which is not the case with
the .hash section. Shouldn't we always take into account
the alignment when calcuating a file position for a section?
0x66d is not 8 byte aligned but 0x670 is.
Any help you can give me would be greatly appreciated!
Thanks!
Reva Cuthbertson
reva@cup.hp.com
> From schwab@suse.de Fri Jun 21 09:29:30 2002
> Received: from hpda.cup.hp.com (hpda.cup.hp.com [15.75.208.53])
> by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id JAA19318
> for <sje@adlmail.cup.hp.com>; Fri, 21 Jun 2002 09:29:30 -0700 (PDT)
> Received: from cuprel1.hp.com (cupona1.hp.com [15.13.176.10])
> by hpda.cup.hp.com (Postfix) with ESMTP id E868D9485
> for <sje@cup.hp.com>; Fri, 21 Jun 2002 09:29:29 -0700 (PDT)
> Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
> by cuprel1.hp.com (Postfix) with ESMTP id 5A902CD6
> for <sje@cup.hp.com>; Fri, 21 Jun 2002 09:29:24 -0700 (PDT)
> Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201])
> by Cantor.suse.de (Postfix) with ESMTP
> id C296A1480B; Fri, 21 Jun 2002 18:28:14 +0200 (MEST)
> X-Authentication-Warning: sykes.suse.de: schwab set sender to schwab@suse.de using -f
> To: Steve Ellcey <sje@cup.hp.com>
> Cc: binutils@sources.redhat.com, amodra@bigpond.net.au
> Subject: Re: copy_private_bfd_data in bfd/elf.c question
> References: <200206211526.IAA18732@hpsje.cup.hp.com>
> X-Yow: YOW!! Now I understand advanced MICROBIOLOGY
> and th' new TAX REFORM laws!!
> From: Andreas Schwab <schwab@suse.de>
> Date: Fri, 21 Jun 2002 18:28:10 +0200
> In-Reply-To: <200206211526.IAA18732@hpsje.cup.hp.com> (Steve Ellcey's
> message of "Fri, 21 Jun 2002 08:26:47 -0700 (PDT)")
> Message-ID: <jek7osfvfp.fsf@sykes.suse.de>
> Lines: 56
> User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.3.50 (ia64-suse-linux)
> MIME-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
>
> Steve Ellcey <sje@cup.hp.com> writes:
>
> |> > How about posting before/after output of readelf -S -l, so we can
> |> > have a clue as to what is going on.
> |>
> |> Ok, here is an example (on IA64 HP-UX) of using strip on a small
> |> executable where the executable coredumps after being stripped. This is
> |> using the standard binutils without our local changes to
> |> copy_private_bfd_data.
> |>
> |> [hpadl731] $ cat x.c
> |> main ()
> |> {
> |> printf("hi\n");
> |> }
> |> [hpadl731] $ gcc x.c -o x
> |> [hpadl731] $ ./x
> |> hi
> |> [hpadl731] $ readelf -S -I x
> |> There are 33 section headers, starting at offset 0x1778:
> |>
> |> Section Headers:
> |> [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> |> [ 0] NULL 00000000 ffffffff 000000 00 0 0 0
> |> [ 1] .dynamic DYNAMIC 04000178 000178 0000b8 08 A 0 0 8
> |> [ 2] .dynsym DYNSYM 04000230 000230 0001a0 10 A 3 0 8
> |> [ 3] .dynstr STRTAB 040003d0 0003d0 00024a 00 A 0 0 1
> |> [ 4] .hash HASH 04000620 000620 0000a4 00 A 0 0 8
> ^^^^^^
>
> [...]
> |> [hpadl731] $ strip x
> |> [hpadl731] $ ./x
> |> Memory fault(coredump)
> |> [hpadl731] $ readelf -S -I x
> |>
> |> There are 31 section headers, starting at offset 0x11e4:
> |>
> |> Section Headers:
> |> [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> |> [ 0] NULL 00000000 000000 000000 00 0 0 0
> |> [ 1] .dynamic DYNAMIC 04000178 000178 0000b8 08 A 3 0 8
> |> [ 2] .dynsym DYNSYM 04000230 000230 0001a0 10 A 3 0 8
> |> [ 3] .dynstr STRTAB 040003d0 0003d0 00024a 00 A 0 0 1
> |> [ 4] .hash HASH 04000620 00061c 0000a4 04 A 2 0 8
> ^^^^^^
>
> This seems to be the culprit.
>
> Andreas.
>
> --
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>