From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111211 invoked by alias); 12 Feb 2020 18:05:51 -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 111202 invoked by uid 89); 12 Feb 2020 18:05:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=corefile, Environment, H*x:5.0, H*x:Windows X-HELO: sonic302-21.consmr.mail.ir2.yahoo.com Received: from sonic302-21.consmr.mail.ir2.yahoo.com (HELO sonic302-21.consmr.mail.ir2.yahoo.com) (87.248.110.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Feb 2020 18:05:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1581530747; bh=AN4gFTaCdU+qJPFIUUE9puyGU4QbIZC2yKgQyF5rntY=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=EoeoBWy32qzIfknlc2j9GCJ7UDmZupk20WBnd56Gdbci2LTXrxFzwXP4WD+TokiA2oB2Trc/mvlXoOK0cNpSX5Z7lt4epL/8kJ7DZfFQa5r1G0t5IP1VT6e+QnOwc3aoJWYzT1sORA7zp6A8BMlrxtv2fwi9yHBDKbO3xEwLLvbiEQX7201LFp1H/sfF7jhUsr2dP8utTZAE0EAwBvSWM3syt6OTmJsuq4ZrIfX8LV5CcQIGaEj7/WWLBxQqx+EED+TioSgE45W6JheKFMF5mHgIHF3GUCJMUrKF+oK7fwfNf+hlhTKp1IEjCFV7drYEijf30SpAgMYRSD25mBgclw== Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ir2.yahoo.com with HTTP; Wed, 12 Feb 2020 18:05:47 +0000 Date: Wed, 12 Feb 2020 18:05:00 -0000 From: "Hannes Domani via gdb-patches" Reply-To: Hannes Domani To: Gdb-patches Message-ID: <2060919114.3614103.1581530742928@mail.yahoo.com> In-Reply-To: References: <691075103.286431.1581179823782.ref@mail.yahoo.com> <691075103.286431.1581179823782@mail.yahoo.com> <568325237.2257415.1581420878458@mail.yahoo.com> Subject: Re: [PING] [PATCH] Rebase executable to match relocated base address MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00459.txt.bz2 Am Mittwoch, 12. Februar 2020, 05:49:45 MEZ hat Simon Marchi Folgendes geschrieben: > On 2020-02-11 6:34 a.m., Hannes Domani via gdb-patches wrote: > >> This function is needed, but the question is how it should get the base > >> address from the target. > >> > >> The auxv trickery works, but that may have other implications. I'm not > >> sure if GDB won't try to fetch more stuff given we now have an "auxv". > >> And it is also a bit misleading. > > > > I've used this approach for a while now, and never had any problem with= it. > > Also, gnu-nat.c creates a fake auxv entry as well. > > > > > >> Is there some other way one can fetch this data? Registers? Memory? > > > > I'm not sure how that would work. > > If that value was stored in some data structure in the process' memory or > register, we could get it from there.=C2=A0 But that doesn't seem to be t= he case, > it's only given at the create process debug event. Actually, this value is available in the process memory in the Process Environment Block (PEB), and can be accessed via: $_tlb->process_environment_block->image_base_address Based on this, I wrote this alternative: static void windows_solib_create_inferior_hook (int from_tty) { =C2=A0 CORE_ADDR tlb; =C2=A0 if (symfile_objfile && target_get_tib_address (inferior_ptid, &tlb)) =C2=A0=C2=A0=C2=A0 { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gdb_byte addr_buf[8]; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct gdbarch *gdbarch =3D target_gdbarch (= ); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int ptr_bytes, peb_offset, base_offset; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (gdbarch_ptr_bit (gdbarch) =3D=3D 32) =C2=A0=C2=A0 =C2=A0{ =C2=A0=C2=A0 =C2=A0=C2=A0 ptr_bytes =3D 4; =C2=A0=C2=A0 =C2=A0=C2=A0 peb_offset =3D 48; =C2=A0=C2=A0 =C2=A0=C2=A0 base_offset =3D 8; =C2=A0=C2=A0 =C2=A0} =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else =C2=A0=C2=A0 =C2=A0{ =C2=A0=C2=A0 =C2=A0=C2=A0 ptr_bytes =3D 8; =C2=A0=C2=A0 =C2=A0=C2=A0 peb_offset =3D 96; =C2=A0=C2=A0 =C2=A0=C2=A0 base_offset =3D 16; =C2=A0=C2=A0 =C2=A0} =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!target_read_memory (tlb + peb_offset, a= ddr_buf, ptr_bytes)) =C2=A0=C2=A0 =C2=A0{ =C2=A0=C2=A0 =C2=A0=C2=A0 enum bfd_endian byte_order =3D gdbarch_byte_order= (gdbarch); =C2=A0=C2=A0 =C2=A0=C2=A0 CORE_ADDR peb =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 =3D extract_unsigned_integer (addr_bu= f, ptr_bytes, byte_order); =C2=A0=C2=A0 =C2=A0=C2=A0 if (!target_read_memory (peb + base_offset, addr_= buf, ptr_bytes)) =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 { =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CORE_ADDR exec_base =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=3D extract_unsigned_integer (addr_bu= f, ptr_bytes, byte_order); =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CORE_ADDR vmaddr =3D pe_d= ata (exec_bfd)->pe_opthdr.ImageBase; =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (vmaddr !=3D exec_base) =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0objfile_rebase (symfile_objfile, exec= _base - vmaddr); =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0 =C2=A0} =C2=A0=C2=A0=C2=A0 } } I've tested this on 32bit & 64bit, both with and without gdbserver, and it seems to work fine as well. I only have one problem with this approach, it doesn't work with my corefile support for Windows minidumps if TIB or PEB were not included in the minidump file. Before, I created a fake .auxv section, just like I did in gdb.