From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20334 invoked by alias); 8 Jul 2002 21:10:44 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 20314 invoked from network); 8 Jul 2002 21:10:43 -0000 Received: from unknown (HELO palrel11.hp.com) (156.153.255.246) by sources.redhat.com with SMTP; 8 Jul 2002 21:10:43 -0000 Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.244.96.175]) by palrel11.hp.com (Postfix) with ESMTP id D15EF600724; Mon, 8 Jul 2002 14:10:42 -0700 (PDT) Received: from cup.hp.com (gclef.atl.hp.com [15.113.162.82]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id OAA18942; Mon, 8 Jul 2002 14:10:41 -0700 (PDT) Message-ID: <3D29FFD0.F3E81228@cup.hp.com> Date: Mon, 08 Jul 2002 14:16:00 -0000 From: Reva Cuthbertson Organization: Hewlett-Packard Co. X-Accept-Language: en MIME-Version: 1.0 To: Andreas Schwab Cc: amodra@bigpond.net.au, sje@cup.hp.com, binutils@sources.redhat.com Subject: Re: copy_private_bfd_data in bfd/elf.c question References: <3D1CEBE2.40C765DD@cup.hp.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2002-07/txt/msg00174.txt.bz2 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 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."