From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102374 invoked by alias); 13 Jan 2016 13:34:44 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 102359 invoked by uid 89); 13 Jan 2016 13:34:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_40,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=1234, distinguish, struggling, compiler's X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Jan 2016 13:34:41 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1aJLZO-0002hO-Lj from Luis_Gustavo@mentor.com ; Wed, 13 Jan 2016 05:34:38 -0800 Received: from [172.30.9.116] (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.224.2; Wed, 13 Jan 2016 05:34:38 -0800 Subject: Re: Harvard architecture and gdb References: To: James Bowman , "gdb@sourceware.org" From: Luis Machado Reply-To: Luis Machado Message-ID: <5696526C.8000307@codesourcery.com> Date: Wed, 13 Jan 2016 13:34:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00010.txt.bz2 On 01/13/2016 01:32 AM, James Bowman wrote: > I am maintainer for a Harvard architecture target, FT32. > > FT32 has two address spaces, flash and RAM. They both occupy addresses starting at address 0. This is similar to AVR. We use a __flash__ modifier to specify address space 1. > > But I am struggling to understand how to describe the architecture to gdb. In particular FT32 uses address spaces to distinguish between pointers to RAM and flash. But gdb only seems to actually care about address spaces for *pointers*. When gcc writes the debug info for a plain object, it does not emit the DW_AT_address_class field; nor does gdb handle DW_AT_address_class for non-pointer types. So I am at a loss to understand how these two variables would be distinguished by gdb: > > int ram_var = 1234; > __flash__ const int flash_var = 1234; > Right now, they wouldn't be distinguished. > I suspect I have misunderstood something fundamental. Does anyone have any suggestions? Thanks. Though supported by DWARF by means of DW_AT_address_class and also DW_AT_segment, this is not readily available in GDB right now. On the compiler's side, it needs to be adjusted to provide enough debug information about those address spaces for each object being used in the program. On GDB's side, the DWARF machinery and other bits need to be expanded to not assume a single address space and new hooks need to be added to handle reading data properly from those address spaces. One limitation of GDB in this regard is assuming there are only a couple basic pointer types: data and code. Some architectures may have two distinct code pointers of different sizes, for example. So GDB needs to be able to tell when/how to use each. Assuming the compiler and GDB are augmented to understand those, then the DWARF machinery in GDB can call the correct hooks to either read or write from/to flash or RAM. Does this bring some light to your problem?