From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90868 invoked by alias); 16 Aug 2019 18:33:06 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 90860 invoked by uid 89); 16 Aug 2019 18:33:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=wil, HX-Languages-Length:1437 X-HELO: mail-wr1-f42.google.com Received: from mail-wr1-f42.google.com (HELO mail-wr1-f42.google.com) (209.85.221.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Aug 2019 18:33:05 +0000 Received: by mail-wr1-f42.google.com with SMTP id s18so2434616wrn.1 for ; Fri, 16 Aug 2019 11:33:05 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id 91sm18942407wrp.3.2019.08.16.11.33.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Aug 2019 11:33:02 -0700 (PDT) Subject: Re: [PATCH][gdb] Fix gdb.dwarf2/amd64-entry-value-param.exp with -fPIE/-pie To: Tom de Vries , Tom Tromey References: <20190809075424.GA15972@delia> <87h86q4324.fsf@tromey.com> Cc: gdb-patches@sourceware.org, Jan Kratochvil From: Pedro Alves Message-ID: <6c25bce6-baaf-9820-e140-12c0e80fa2cc@redhat.com> Date: Fri, 16 Aug 2019 18:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-08/txt/msg00377.txt.bz2 On 8/12/19 2:10 PM, Tom de Vries wrote: >> Tom> + CORE_ADDR baseaddr >> Tom> + = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile)); >> >> I guess this assumes the text section - but then can the call to >> find_pc_section give anything else? Maybe it's just something to >> comment and move on. >> > I suppose that find_pc_section also can return .init or .fini., but I > imagine these wil have the same sections offsets as .text. > Hmm. That'll usually be the case on GNU/Linux and other standard operating systems, where you have a single text segment containing all sections. But they might well not have the same offsets if you're debugging a relocatable object, for example. Some targets' shared libraries are relocatable objects instead of fully linked binaries. See "Library List Format" in the manual: ~~~ For the common case of libraries that are fully linked binaries, the library should have a list of segments. If the target supports dynamic linking of a relocatable object file, its library XML element should instead include a list of allocated sections. The segment or section bases are start addresses, not relocation offsets; they do not depend on the library's link-time base addresses. ~~~ Linux kernel modules would be something like that too, I think. If easy, it seems better to look up the section. Thanks, Pedro Alves