From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25822 invoked by alias); 23 Apr 2010 15:50:06 -0000 Received: (qmail 25615 invoked by uid 22791); 23 Apr 2010 15:50:03 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.35) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Apr 2010 15:49:59 +0000 Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [10.3.21.1]) by smtp-out.google.com with ESMTP id o3NFnup8023093 for ; Fri, 23 Apr 2010 17:49:56 +0200 Received: from wyb40 (wyb40.prod.google.com [10.241.225.104]) by hpaq1.eem.corp.google.com with ESMTP id o3NFns0I019762 for ; Fri, 23 Apr 2010 17:49:55 +0200 Received: by wyb40 with SMTP id 40so822221wyb.35 for ; Fri, 23 Apr 2010 08:49:54 -0700 (PDT) Received: by 10.216.173.202 with SMTP id v52mr270111wel.200.1272037794553; Fri, 23 Apr 2010 08:49:54 -0700 (PDT) Received: from coign.google.com (dhcp-172-22-126-240.mtv.corp.google.com [172.22.126.240]) by mx.google.com with ESMTPS id d16sm567500wej.21.2010.04.23.08.49.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Apr 2010 08:49:53 -0700 (PDT) To: "H.J. Lu" Cc: John Reiser , binutils@sourceware.org Subject: Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel) References: <4BBF7F0B.10508@gmail.com> <4BD0BEC8.8050609@bitwagon.com> From: Ian Lance Taylor Date: Fri, 23 Apr 2010 15:50:00 -0000 In-Reply-To: (H. J. Lu's message of "Fri\, 23 Apr 2010 08\:30\:11 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00377.txt.bz2 "H.J. Lu" writes: > On Fri, Apr 23, 2010 at 8:16 AM, Ian Lance Taylor wrote: >> "H.J. Lu" writes: >> >>> Program Headers: >>> =C2=A0 Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Offset =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 VirtAddr =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PhysAd= dr >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FileSiz = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MemSiz =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Flags =C2=A0Align >>> =C2=A0 LOAD =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0000000000001000 0x000= 0000000000000 0x0000000000000000 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0000000= 000000001 0x0000000000000001 =C2=A0R E =C2=A0 =C2=A01000 >>> =C2=A0 LOAD =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0000000000002000 0x000= 0000000004000 0x0000000000004000 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0000000= 000002001 0x0000000000002001 =C2=A0RW =C2=A0 =C2=A0 4000 >> >> This looks right to me. >> >> >>> I am not sure it is a good idea to have different p_align. >> >> Why not? =C2=A0How else can we communicate the information requested by = the >> programmer? =C2=A0A system which cares about p_align needs to look at the >> p_align of each PT_LOAD header. > > You can't load the first segment with 0x1000 alignment. You > need to load the first segment with the alignment of the second > segment. Why does gold have to make life harder for loader? The Linux kernel doesn't look at the p_align field, nor should it. The p_align field is clearly irrelevant when loading an executable. The glibc dynamic linker checks that the p_align field looks plausible, but otherwise ignores it other than for a PT_TLS segment; that seems appropriate since ld.so is restricted to what mmap does anyhow. In general, it's hard for me to think of why any loader on a virtual memory system would look at the p_align field. And it's hard for to think of any non-virtual memory system that would support ELF style shared libraries. So I think you are raising a purely hypothetical concern. On the other hand the p_align field does convey information about the sections in that particular segment, and that seems reasonable to me. Ian