From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from imta-38.everyone.net (imta-37.everyone.net [216.200.145.37]) by sourceware.org (Postfix) with ESMTPS id 4F0ED3857C75 for ; Thu, 3 Jun 2021 18:55:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F0ED3857C75 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=lcwb.coop Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=lcwb.coop Received: from pps.filterd (localhost.localdomain [127.0.0.1]) by imta-38.everyone.net (8.16.0.43/8.16.0.43) with SMTP id 153Iq0xh019440; Thu, 3 Jun 2021 11:54:47 -0700 X-Eon-Originating-Account: U78emtZQUPFmBGsaWOGDikTGOmCJ-6fdLS77vBXc1chjdlQWGkOsjIpXeupkbJqA X-Eon-Dm: m0117124.ppops.net Received: by m0117124.mta.everyone.net (EON-AUTHRELAY2 - a248a996) id m0117124.60b7071e.17907; Thu, 3 Jun 2021 11:54:44 -0700 X-Eon-Sig: AQNpay9guSV0wBLltAIAAAAD,ee6021a6cf3cc8e6383330da46eec4f2 X-Eip: bcuaNQ3l_hrupkVc-WinmPHb71TYUIw50SLyTrCmvhM Reply-To: rodney.m.bates@acm.org Subject: Re: Change in relocation of debug info To: Simon Marchi , rodney.m.bates@acm.org, gdb@sourceware.org References: <83239e44-c732-7dad-56b6-b12c98dc6795@polymtl.ca> From: "Rodney M. Bates" Message-ID: Date: Thu, 3 Jun 2021 13:54:36 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <83239e44-c732-7dad-56b6-b12c98dc6795@polymtl.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: nUY6Sko_YeolUA8jib3gHOqcGlL80vFF X-Proofpoint-GUID: nUY6Sko_YeolUA8jib3gHOqcGlL80vFF X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-03_12:2021-06-03, 2021-06-03 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 mlxlogscore=876 priorityscore=1501 mlxscore=0 adultscore=0 bulkscore=0 spamscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106030128 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, 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: Thu, 03 Jun 2021 18:55:06 -0000 On 5/31/21 10:08 AM, Simon Marchi via Gdb wrote: >> 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 > Thanks. Using -f=no-pie has gotten me going for now. My build process has been supplying -fPIC for ages, to the older gcc, so I don't fully understand why it wasn't happening all along, but this works for now. -- Rodney Bates rodney.m.bates@acm.org