Re: copy_private_bfd_data in bfd/elf.c question

Re: copy_private_bfd_data in bfd/elf.c question

[Reva Cuthbertson]

Hello,

    I am still looking at code in copy_private_bfd_data()
which is causing problems with strip and objcopy on
IA-64 HP-UX.   When the binutils version of strip and
objcopy are used on HP-UX, the resulting program gets
a segmentation violation when it is executed.  As Andreas
pointed out in:

http://sources.redhat.com/ml/binutils/2002-06/msg00762.html

the cause for the segmentation violation was because strip
and objcopy were changing the offset of the .hash section.  The
change in offset happens in assign_file_positions_for_segments()
which uses the segment's p_paddr field to calcuate the new position.
Unfortunately, the new position is not correctly aligned which
causes the segmentation violation.

    The HP Linker sets the p_paddr field of all of the segments to 0.
There is code in copy_private_bfd_data() which detects this and
tries to "fix" things.  From the comments, it appears that this is
done because the Solaris linker also sets p_paddr to 0.  The
code in copy_private_bfd_data() is the following:

        /* 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;


            I am not sure why this code was needed for Solaris but
it needs to be disabled for HP-UX on IA-64.  According to my
ELF Document it says that the p_paddr field of the program
header (segment) is reserved for systems with physical addressing.
HP-UX is not such a system and therefore I believe that p_paddr should
be left as 0.  (It probably should be left as 0 for all systems which
do not do physical addressing, but that is another matter).  In
any case, I tried to work around the fact that p_paddr is
recalculated by playing with section alignment but I ran into further
problems in assign_file_positons_for_segments().  I believe
the real fix is to disable setting p_paddr in copy_private_bfd_data().

    I do have a fix for this which works on HP-UX.  However, the
fix involves a compile-time check and I understand that compile-time
checks are discouraged in bfd.  Is there a runtime check that
would do the same thing or do I need my own version of
copy_private_bfd_data()?  Here is what I want to do:

#ifndef NO_PHYSICAL_ADDRESSING
              /* 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;
#endif
              /* Match up the physical address of the segment with the
                 LMA address of the output section.  */
              if (IS_CONTAINED_BY_LMA (output_section, segment,
map->p_paddr)
                  || IS_CONTAINED_BY_FILEPOS (section, segment, bed)
#ifndef NO_PHYSICAL_ADDRESSING
                  || IS_COREFILE_NOTE (segment, section))
#else
                  || IS_COREFILE_NOTE (segment, section)
                  || IS_CONTAINED_BY_VMA (output_section, segment))
#endif

                {
                  if (matching_lma == 0)
                    matching_lma = output_section->lma;

                  /* We assume that if the section fits within the
segment
                     then it does not overlap any other section within
that
                     segment.  */
                  map->sections[isec ++] = output_section;
                }
              else if (suggested_lma == 0)
                suggested_lma = output_section->lma;
            }
        }


Is there an acceptable way to do this?

Thanks so much!

Reva Cuthbertson
reva@cup.hp.com

Re: copy_private_bfd_data in bfd/elf.c question

[Nick Clifton]

Hi Reva.

>     Thanks so much for the patch!  I tried it out on HP-UX/IA-64
> with objcopy and strip and it worked for me.  Could you check these
> changes in as I do not have write access?

I have checked the patch into the mainline sources.

> Would it be possible to get these changes into the 2.13 branch as
> well as the mainline?

Hmm, well that would be up to Daniel.  Since the patch is adding a new
"feature" I would be reluctant to apply it, but since this feature
fixes a bug with the HP-UX IA-64 port I might be tempted to accept it.

Cheers
        Nick


> 2002-07-19  Nick Clifton  <nickc@redhat.com>
>
>         * elf-bfd.h (struct elf_backend_data): Add new bitfield
>         'want_p_paddr_set_zero'.
>         * elfxx-target.h: Set default value for want_p_paddr_set_zero
>         to false;
>         * elfxx-ia64.c: Set want_p_paddr_set_zero for HPUX target.
>         * elf.c (copy_private_bfd_data): Test want_p_paddr_set_zero.

Re: copy_private_bfd_data in bfd/elf.c question

[Nick Clifton]

Hi Daniel,

> The patch looks safe to me, so I agree with Nick - it should go on the
> branch.  We're a little behind schedule anyway.
> 
> Nick, could you take care of this, or should I?  I don't have the
> original patch.

I will take care of it.

Cheers
        Nick

Re: copy_private_bfd_data in bfd/elf.c question

[Daniel Jacobowitz]

The patch looks safe to me, so I agree with Nick - it should go on the
branch.  We're a little behind schedule anyway.

Nick, could you take care of this, or should I?  I don't have the
original patch.

On Tue, Jul 23, 2002 at 09:08:36AM -0700, Steve Ellcey wrote:
> Daniel,
> 
> Are you acting as the 2.13 release manager?  I would like to know if it
> is too late to get this patch in for 2.13?  I see that today is the
> planned freeze date.  The full patch is at
> http://sources.redhat.com/ml/binutils-cvs/2002-07/msg00165.html and it
> fixes a bug in objcopy & strip on the HP-UX IA64 platform.
> 
> I probably wouldn't call this fix critical, mainly because this platform
> is not very widespread yet.  But without the patch objcopy and strip are
> unusable on HP-UX IA64.  Perhaps we could put it into the branch for a
> future 2.13.1 release if you don't want to risk putting it in to 2.13 at
> this late date.
> 
> Steve Ellcey
> sje@cup.hp.com
> 
> > Date: 23 Jul 2002 12:19:54 +0100
> > In-Reply-To: <3D3C766C.91969D78@cup.hp.com>
> > Message-ID: <m37kjmpu79.fsf@north-pole.nickc.cambridge.redhat.com>
> > Lines: 27
> > User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > 
> > Hi Reva.
> > 
> > >     Thanks so much for the patch!  I tried it out on HP-UX/IA-64
> > > with objcopy and strip and it worked for me.  Could you check these
> > > changes in as I do not have write access?
> > 
> > I have checked the patch into the mainline sources.
> > 
> > > Would it be possible to get these changes into the 2.13 branch as
> > > well as the mainline?
> > 
> > Hmm, well that would be up to Daniel.  Since the patch is adding a new
> > "feature" I would be reluctant to apply it, but since this feature
> > fixes a bug with the HP-UX IA-64 port I might be tempted to accept it.
> > 
> > Cheers
> >         Nick
> > 
> > 
> > > 2002-07-19  Nick Clifton  <nickc@redhat.com>
> > >
> > >         * elf-bfd.h (struct elf_backend_data): Add new bitfield
> > >         'want_p_paddr_set_zero'.
> > >         * elfxx-target.h: Set default value for want_p_paddr_set_zero
> > >         to false;
> > >         * elfxx-ia64.c: Set want_p_paddr_set_zero for HPUX target.
> > >         * elf.c (copy_private_bfd_data): Test want_p_paddr_set_zero.
> 

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: copy_private_bfd_data in bfd/elf.c question

[Steve Ellcey]

Daniel,

Are you acting as the 2.13 release manager?  I would like to know if it
is too late to get this patch in for 2.13?  I see that today is the
planned freeze date.  The full patch is at
http://sources.redhat.com/ml/binutils-cvs/2002-07/msg00165.html and it
fixes a bug in objcopy & strip on the HP-UX IA64 platform.

I probably wouldn't call this fix critical, mainly because this platform
is not very widespread yet.  But without the patch objcopy and strip are
unusable on HP-UX IA64.  Perhaps we could put it into the branch for a
future 2.13.1 release if you don't want to risk putting it in to 2.13 at
this late date.

Steve Ellcey
sje@cup.hp.com

> Date: 23 Jul 2002 12:19:54 +0100
> In-Reply-To: <3D3C766C.91969D78@cup.hp.com>
> Message-ID: <m37kjmpu79.fsf@north-pole.nickc.cambridge.redhat.com>
> Lines: 27
> User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> 
> Hi Reva.
> 
> >     Thanks so much for the patch!  I tried it out on HP-UX/IA-64
> > with objcopy and strip and it worked for me.  Could you check these
> > changes in as I do not have write access?
> 
> I have checked the patch into the mainline sources.
> 
> > Would it be possible to get these changes into the 2.13 branch as
> > well as the mainline?
> 
> Hmm, well that would be up to Daniel.  Since the patch is adding a new
> "feature" I would be reluctant to apply it, but since this feature
> fixes a bug with the HP-UX IA-64 port I might be tempted to accept it.
> 
> Cheers
>         Nick
> 
> 
> > 2002-07-19  Nick Clifton  <nickc@redhat.com>
> >
> >         * elf-bfd.h (struct elf_backend_data): Add new bitfield
> >         'want_p_paddr_set_zero'.
> >         * elfxx-target.h: Set default value for want_p_paddr_set_zero
> >         to false;
> >         * elfxx-ia64.c: Set want_p_paddr_set_zero for HPUX target.
> >         * elf.c (copy_private_bfd_data): Test want_p_paddr_set_zero.

Re: copy_private_bfd_data in bfd/elf.c question

[Reva Cuthbertson]

Andreas,

    Thanks for the response!  I just got back into the office
today and had a chance to dig further.  It appears that
in bfd, the flags for the .hash section contain both
SEC_ALLOC and SEC_LOAD.   Unfortunately, this is a problem
in assign_file_positions_for_segments() because we check
for SEC_LOAD first and we only check for SEC_ALLOC IF
SEC_LOAD was not set:

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;
       }
       else if ((flags & SEC_ALLOC) != 0)
       {
         /* The section VMA must equal the file position
             modulo the page size.  FIXME: I'm not sure if
             this adjustment is really necessary.  We used to
             not have the SEC_LOAD case just above, and then
             this was necessary, but now I'm not sure.  */
         if ((abfd->flags & D_PAGED) != 0)
           adjust = (sec->vma - voff) % bed->maxpagesize;
         else
           adjust = (sec->vma - voff) % align;
        }

In this code, if the flags for the .hash section did not include SEC_LOAD,
we would have executed the "else" statement and taken alignment into
account.  However, for some reason the flags did include SEC_LOAD so
we never took alignment into account.    I don't know where the flags
for the .hash section get set in bfd.  In particular, I do not know why
the .hash section flags contain SEC_LOAD.  Does this look right?  If so,
shouldn't we take always take alignment into account when calculating
"adjust"?

Thanks!

Reva Cuthbertson
reva@cup.hp.com

Andreas Schwab wrote:

> Reva Cuthbertson <reva@cup.hp.com> writes:
>
> |> 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.
>
> That looks odd.  The secion flags of .hash include SHF_ALLOC, which
> should be translated to SEC_ALLOC in BFD.  If .hash isn't SEC_ALLOC then
> something is wrong here.
>
> 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."

Re: copy_private_bfd_data in bfd/elf.c question

[Andreas Schwab]

Reva Cuthbertson <reva@cup.hp.com> writes:

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

That looks odd.  The secion flags of .hash include SHF_ALLOC, which
should be translated to SEC_ALLOC in BFD.  If .hash isn't SEC_ALLOC then
something is wrong here.

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

Re: copy_private_bfd_data in bfd/elf.c question

[Reva Cuthbertson]

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

Re: copy_private_bfd_data in bfd/elf.c question

[Steve Ellcey]

> Note to Steve: -l not -I !  I was curious as to whether the segment
> map changed.  If it didn't then no matter.

Oops, I guess I need a better font in my mailer.  It looks like the
segment map did change, at least a little, ".bortext" is missing from
segment 04 and .note is missing from 08.  I have no idea what this
means, I don't recall ever seeing a .bortext section before.

Old (pre-strip):

 Section to Segment mapping:
  Segment Sections...
   00
   01     .IA_64.unwind_hdr .IA_64.unwind .IA_64.unwind_info
   02     .interp
   03     .dynamic
   04     .dynamic .dynsym .dynstr .hash .rela.plt .IA_64.unwind_hdr .IA_64.unwind .IA_64.unwind_info .rodata .interp .dynhash .text .bortext
   05     .plt .dlt .sbss .bss
   06
   07
   08     .note
   09

New (after running strip):

 Section to Segment mapping:
  Segment Sections...
   00
   01     .IA_64.unwind_hdr .IA_64.unwind .IA_64.unwind_info
   02     .interp
   03     .dynamic
   04     .dynamic .dynsym .dynstr .hash .rela.plt .IA_64.unwind_hdr .IA_64.unwind .IA_64.unwind_info .rodata .interp .dynhash .text
   05     .plt .dlt .sbss .bss
   06
   07
   08
   09

Re: copy_private_bfd_data in bfd/elf.c question

[Alan Modra]

On Sun, Jun 23, 2002 at 02:35:52PM +0930, Alan Modra wrote:
> On Sat, Jun 22, 2002 at 09:23:10PM +0200, Andreas Schwab wrote:
> > Alan Modra <amodra@bigpond.net.au> writes:
> > 
> > |> On Fri, Jun 21, 2002 at 06:28:10PM +0200, Andreas Schwab wrote:
> > |> > 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.
> > |> 
> > |> Note to Steve: -l not -I !  I was curious as to whether the segment
> > |> map changed.  If it didn't then no matter.
> > |> 
> > |> > |>   [ 4] .hash             HASH            04000620 000620 0000a4 00   A  0   0  8
> > |> [snip]
> > |> > |>   [ 4] .hash             HASH            04000620 00061c 0000a4 04   A  2   0  8
> > |> > 
> > |> > This seems to be the culprit.
> > |> 
> > |> sizeof_hash_entry == 4, so why does this matter?
> > 
> > But align == 8, and addr and off don't agree in the low 3 bits.
> 
> OK, it's different, but why does it matter?  Is there something that
> says section alignment should affect file alignment?  I'm more worried
> about Steve's report that objcopy resulted in a file that segv'd than
> in a file that was different in what seems to me a fairly
> insignificant way.

Duh.  Fired that email off too quick.  Of course it matters.  File
loading is done by segments, not sections.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: copy_private_bfd_data in bfd/elf.c question

[Alan Modra]

On Sat, Jun 22, 2002 at 09:23:10PM +0200, Andreas Schwab wrote:
> Alan Modra <amodra@bigpond.net.au> writes:
> 
> |> On Fri, Jun 21, 2002 at 06:28:10PM +0200, Andreas Schwab wrote:
> |> > 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.
> |> 
> |> Note to Steve: -l not -I !  I was curious as to whether the segment
> |> map changed.  If it didn't then no matter.
> |> 
> |> > |>   [ 4] .hash             HASH            04000620 000620 0000a4 00   A  0   0  8
> |> [snip]
> |> > |>   [ 4] .hash             HASH            04000620 00061c 0000a4 04   A  2   0  8
> |> > 
> |> > This seems to be the culprit.
> |> 
> |> sizeof_hash_entry == 4, so why does this matter?
> 
> But align == 8, and addr and off don't agree in the low 3 bits.

OK, it's different, but why does it matter?  Is there something that
says section alignment should affect file alignment?  I'm more worried
about Steve's report that objcopy resulted in a file that segv'd than
in a file that was different in what seems to me a fairly
insignificant way.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: copy_private_bfd_data in bfd/elf.c question

[Andreas Schwab]

Alan Modra <amodra@bigpond.net.au> writes:

|> On Fri, Jun 21, 2002 at 06:28:10PM +0200, Andreas Schwab wrote:
|> > 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.
|> 
|> Note to Steve: -l not -I !  I was curious as to whether the segment
|> map changed.  If it didn't then no matter.
|> 
|> > |>   [ 4] .hash             HASH            04000620 000620 0000a4 00   A  0   0  8
|> [snip]
|> > |>   [ 4] .hash             HASH            04000620 00061c 0000a4 04   A  2   0  8
|> > 
|> > This seems to be the culprit.
|> 
|> sizeof_hash_entry == 4, so why does this matter?

But align == 8, and addr and off don't agree in the low 3 bits.

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

Re: copy_private_bfd_data in bfd/elf.c question

[Alan Modra]

On Fri, Jun 21, 2002 at 06:28:10PM +0200, Andreas Schwab wrote:
> 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.

Note to Steve: -l not -I !  I was curious as to whether the segment
map changed.  If it didn't then no matter.

> |>   [ 4] .hash             HASH            04000620 000620 0000a4 00   A  0   0  8
[snip]
> |>   [ 4] .hash             HASH            04000620 00061c 0000a4 04   A  2   0  8
> 
> This seems to be the culprit.

sizeof_hash_entry == 4, so why does this matter?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: copy_private_bfd_data in bfd/elf.c question

[Andreas Schwab]

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

Re: copy_private_bfd_data in bfd/elf.c question

[Steve Ellcey]

> 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
  [ 5] .rela.plt         RELA            040006c4 0006c4 00000c 0c   A  2   0  4
  [ 6] .IA_64.unwind_hdr PROGBITS        040006d0 0006d0 000018 00   A  0   0  8
  [ 7] .IA_64.unwind     IA_64_UNWIND    040006e8 0006e8 00000c 04   A  0   d  4
  [ 8] .IA_64.unwind_inf PROGBITS        040006f4 0006f4 000018 00   A  0   0  4
  [ 9] .rodata           PROGBITS        04000710 000710 000008 00   A  0   0  8
  [10] .interp           PROGBITS        04000718 000718 00002e 00   A  0   0  1
  [11] .dynhash          PROGBITS        04000748 000748 000068 00   A  0   0  8
  [12] .opd              PROGBITS        040007b0 0007b0 000000 00   A  0   0  8
  [13] .text             PROGBITS        040007b0 0007b0 000080 00  AX  0   0 16
  [14] .bortext          PROGBITS        04000830 000830 000040 00  AX  0   0 16
  [15] .data             PROGBITS        40000000 001000 000000 00  WA  0   0  1
  [16] .HP.init          PROGBITS        40000000 001000 000000 00  WA  0   0  4
  [17] .HP.preinit       PROGBITS        40000000 001000 000000 00  WA  0   0  4
  [18] .init_array       INIT_ARRAY      40000000 001000 000000 00  WA  0   0  4
  [19] .preinit_array    PREINIT_ARRAY   40000000 001000 000000 00  WA  0   0  4
  [20] .fini_array       FINI_ARRAY      40000000 001000 000000 00  WA  0   0  4
  [21] .plt              PROGBITS        40000000 001000 000010 10 WAp  0   0  8
  [22] .dlt              PROGBITS        40000010 001010 000008 08 WAp  0   0  8
  [23] .sbss             NOBITS          40000018 001018 000018 00 WAp  0   0  8
  [24] .bss              NOBITS          40000030 001018 000008 00  WA  0   0  8
  [25] .hbss             NOBITS          40000038 001018 000000 00  WA  0   0  8
  [26] .tbss             NOBITS          40000038 001018 000000 00 WAo  0   0  8
  [27] .fastbind         PROGBITS        00000000 001018 000000 00      0   0  1
  [28] .note             NOTE            00000000 001018 000098 00      0   0  4
  [29] .comment          PROGBITS        00000000 0010b0 000028 00      0   0  1
  [30] .strtab           STRTAB          00000000 0010d8 00020a 00      0   0  4
  [31] .symtab           SYMTAB          00000000 0012e8 000370 10     30  21  8
  [32] .shstrtab         STRTAB          00000000 001658 000120 00      0   0  4
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Histogram for bucket list length (total of 13 buckets):
 Length  Number     % of total  Coverage
      0  3          ( 23.1%)
      1  4          ( 30.8%)     19.0%
      2  2          ( 15.4%)     38.1%
      3  3          ( 23.1%)     81.0%
      4  1          (  7.7%)    100.0%

[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
  [ 5] .rela.plt         RELA            040006c4 0006c0 00000c 0c   A  2  15  4
  [ 6] .IA_64.unwind_hdr PROGBITS        040006d0 0006cc 000018 00   A  0   0  8
  [ 7] .IA_64.unwind     IA_64_UNWIND    040006e8 0006e4 00000c 04  AL 13   d  4
  [ 8] .IA_64.unwind_inf PROGBITS        040006f4 0006f0 000018 00   A  0   0  4
  [ 9] .rodata           PROGBITS        04000710 00070c 000008 00   A  0   0  8
  [10] .interp           PROGBITS        04000718 000714 00002e 00   A  0   0  1
  [11] .dynhash          PROGBITS        04000748 000744 000068 00   A  0   0  8
  [12] .opd              PROGBITS        040007b0 0007ac 000000 00   A  0   0  8
  [13] .text             PROGBITS        040007b0 0007ac 000080 00  AX  0   0 16
  [14] .bortext          PROGBITS        04000830 00082c 000040 00  AX  0   0 16
  [15] .data             PROGBITS        40000000 001000 000000 00  WA  0   0  1
  [16] .HP.init          PROGBITS        40000000 001000 000000 00  WA  0   0  4
  [17] .HP.preinit       PROGBITS        40000000 001000 000000 00  WA  0   0  4
  [18] .init_array       INIT_ARRAY      40000000 001000 000000 00  WA  0   0  4
  [19] .preinit_array    PREINIT_ARRAY   40000000 001000 000000 00  WA  0   0  4
  [20] .fini_array       FINI_ARRAY      40000000 001000 000000 00  WA  0   0  4
  [21] .plt              PROGBITS        40000000 001000 000010 10 WAp  0   0  8
  [22] .dlt              PROGBITS        40000010 001010 000008 08 WAp  0   0  8
  [23] .sbss             NOBITS          40000018 001018 000018 00 WAp  0   0  8
  [24] .bss              NOBITS          40000030 001018 000008 00  WA  0   0  8
  [25] .hbss             NOBITS          40000038 001018 000000 00  WA  0   0  8
  [26] .tbss             NOBITS          40000038 001018 000000 00  WA  0   0  8
  [27] .fastbind         PROGBITS        00000000 001018 000000 00      0   0  1
  [28] .note             NOTE            00000000 001018 000098 00      0   0  4
  [29] .comment          PROGBITS        00000000 0010b0 000028 00      0   0  1
  [30] .shstrtab         STRTAB          00000000 0010d8 00010b 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Histogram for bucket list length (total of 26 buckets):
 Length  Number     % of total  Coverage
      0  26         (100.0%)

Re: copy_private_bfd_data in bfd/elf.c question

[Alan Modra]

On Thu, Jun 20, 2002 at 10:14:43AM -0700, Steve Ellcey wrote:
> Now, on IA64 HP-UX we found that the native linker (we didn't port gld)
> also sets p_paddr to 0 and we were entering this if statement but doing
> so caused us problems.  With this standard elf.c we found that running
> objcopy and/or strip could result in objects that grew in size and/or
> did a seg fault when we executed them.

How about posting before/after output of readelf -S -l, so we can
have a clue as to what is going on.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

copy_private_bfd_data in bfd/elf.c question

[Steve Ellcey]

While porting gas and binutils to the HP-UX IA64 platform we were mostly
interested in gas but we also did some work to try and make sure that
the binutils tools (nm, objcopy, etc) worked and we have run into a
problem in copy_private_bfd_data in bfd/elf.c.

The problem centers around map->p_paddr.

copy_private_bfd_data has the following code:

              /* 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;

Now, on IA64 HP-UX we found that the native linker (we didn't port gld)
also sets p_paddr to 0 and we were entering this if statement but doing
so caused us problems.  With this standard elf.c we found that running
objcopy and/or strip could result in objects that grew in size and/or
did a seg fault when we executed them.

Our current workaround is to comment out this code and then in the
following if statement where IS_CONTAINED_BY_LMA is checked to also
check IS_CONTAINED_BY_VMA and do the setting of map->sections if that is
true.

Unfortunately, I am not an elf expert and I don't know if the current
code or our changes can or should be considered correct and I don't know
how or if we can make the changes we want in a manner that won't affect
other platforms.  So I am looking for any advice people can offer on
what we should be doing and/or how it should be done.

Steve Ellcey
sje@cup.hp.com