From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23194 invoked by alias); 17 Feb 2005 01:22:32 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 23176 invoked by uid 48); 17 Feb 2005 01:22:26 -0000 Date: Thu, 17 Feb 2005 12:45:00 -0000 Message-ID: <20050217012226.23175.qmail@sourceware.org> From: "schlie at comcast dot net" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20041220095410.19087.tsandnes@atmel.com> References: <20041220095410.19087.tsandnes@atmel.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/19087] Overflowed address in dwarf debug line information X-Bugzilla-Reason: CC X-SW-Source: 2005-02/txt/msg01886.txt.bz2 List-Id: ------- Additional Comments From schlie at comcast dot net 2005-02-17 01:22 ------- Not sure if it's helpful (or further complicating) but as the avr uses a Harvard memory model; it's PC (program counter) actually references a 64K 16-bit program word address space which is orthogonal to it's 64KB data memory space (although a few specialized instructions do allow restrictive reference to it's program address space). So wonder if program address should actually more simply be pre-scaled as being a word address, not byte address, thereby only requiring 16-bit (2 byte) program references by compiler/sssembler/etc.; thereby possibly sidestepping the otherwise necessity for a wider type to store program debug references (so coincidently wonder if this problem should also be simultaneously reported against binutils/gas/ld avr tools; which reminds me that I recall a few patches being checked in to cvs for gas/HEAD which extended it to support 16-bit (up from 15-bit) displacements, which may be a step along the path to a solution of the problems observed?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087