From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 738 invoked by alias); 6 Sep 2005 18:38:59 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 551 invoked by uid 22791); 6 Sep 2005 18:38:34 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 06 Sep 2005 18:38:34 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j86IcWhp032442; Tue, 6 Sep 2005 14:38:32 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j86IcSV27994; Tue, 6 Sep 2005 14:38:28 -0400 Received: from alligator.red-bean.com.redhat.com (vpn26-14.sfbay.redhat.com [172.16.26.14]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j86IcNqJ027217; Tue, 6 Sep 2005 14:38:24 -0400 To: binutils@sourceware.org Cc: ddiky@alarity.com Subject: Re: dwarf2 and linker relaxation problem References: <200509012036.51309.ddiky@alarity.com> From: Jim Blandy Date: Tue, 06 Sep 2005 19:32:00 -0000 In-Reply-To: (Ian Lance Taylor's message of "01 Sep 2005 19:51:18 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-09/txt/msg00070.txt.bz2 Ian Lance Taylor writes: > Jim Blandy writes: >> Ian Lance Taylor writes: >> > Dmitry Diky writes: >> >> I am experiencing some problems with keeping dwarf2 info intact after linker >> >> relaxation. So, if linker relax section, the line info references are shifted >> >> by the number of deleted bytes. >> >> Is there any example which shows how to fix this problem? >> > >> > I believe this works on the SH. See sh_elf_relax_delete_bytes in >> > elf32-sh.c. >> >> Which part of that affects the .debug_line sections? > > The part that handles the R_SH_SWITCH* relocs. > > Not that I've checked it, but that's the right place to look. These days the assembler produces .debug_line sections that use the Dwarf special opcodes: $ readelf -wl bfd/archive.o ... Line Number Statements: Extended opcode 2: set Address to 0x0 Advance Line by 161 to 162 Copy Special opcode 92: advance Address by 6 to 0x6 and Line by 3 to 165 Advance PC by constant 17 to 0x17 Special opcode 62: advance Address by 4 to 0x1b and Line by 1 to 166 Advance PC by constant 17 to 0x2c ... $ If the linker changes the length of an instruction between 0 and 6, say, then that Dwarf special opcode needs to be changed. I don't see how any existing SH reloc could be shoehorned into fixing that. And then, since the special opcodes only have limited ranges, a relaxation could require you to switch from a special opcode to something more general, like a DW_LNS_advance_pc. This is why, as Richard says, in order to do relaxation in the presence of modern Dwarf line info, the linker needs to read the line number info, do the relaxations while adjusting the machine / source mapping as needed, and then re-emit the line number info. I didn't see anything to do this in the BFD code --- thus my question.