From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 90F4F385702D for ; Mon, 31 May 2021 15:08:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 90F4F385702D Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 14VF8gNm029175 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 May 2021 11:08:47 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 14VF8gNm029175 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 47DAE1E940; Mon, 31 May 2021 11:08:42 -0400 (EDT) Subject: Re: Change in relocation of debug info To: rodney.m.bates@acm.org, gdb@sourceware.org References: From: Simon Marchi Message-ID: <83239e44-c732-7dad-56b6-b12c98dc6795@polymtl.ca> Date: Mon, 31 May 2021 11:08:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 31 May 2021 15:08:42 +0000 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2021 15:08:52 -0000 > When I link using gcc 5.4: > > $gcc --version: > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609, > > giving executable named prog I see: > > $objdump -g prog > ... > /* file ../src/SetElem.m3 line 11 addr 0x4008ee */ > ... > But when linking with gcc 9.3: > > $gcc --version: > gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 > > I see: > > $objdump -g prog > ... > /* file ../src/SetElem.m3 line 11 addr 0x9b1 */ It just sounds like your gcc 9.3.0 is producing position-indenpendent executables by default, whereas your gcc 5.4.0 did not. In the recent years, this has become the norm. The executable produced by your gcc 5.4.0 is made to always be loaded at the same address, so the code at virtual address 0x4008ee in the executable will always end up at address 0x4008ee in the virtual address space of the process. With the executable produced by your gcc 9.3.0, the OS / dynamic linker will choose a different random base address for the executable every time it's loaded (except when address randomization is disabled, which GDB tries to do by default, then it will always be the same random address). So the virtual address 0x9b1 in the executable will end up at + 0x9b1 in the virtual address space of the process. GDB has to account for that: detect the load address of the executable, adjust the addresses of the symbols. This works for DWARF but doesn't seem to work for stabs for some reason (based on what you have shown, I didn't try it myself). I don't know how difficult it would be to make it work for stabs, but it's unlikely that anybody working on GDB will do it, given that stabs is pretty much a dead format. You can try if you want though. An alternative is to instruct your gcc 9.3.0 to produce good old position-dependent executables, as your gcc 5.4.0 does. This is done using -fno-pie at link time, IIRC. Simon