From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32298 invoked by alias); 29 May 2003 23:22:37 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32207 invoked from network); 29 May 2003 23:22:36 -0000 Received: from unknown (HELO stardust.solidas.com) (217.13.28.68) by sources.redhat.com with SMTP; 29 May 2003 23:22:36 -0000 Received: from solidas.com (217-13-28-83.dd.nextgentel.com [217.13.28.83]) (authenticated) by stardust.solidas.com (8.11.6/8.11.6) with ESMTP id h4TNMZl03359 for ; Fri, 30 May 2003 01:22:35 +0200 Message-ID: <3ED6964E.2080509@solidas.com> Date: Thu, 29 May 2003 23:22:00 -0000 From: "Svein E. Seldal" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030521 Debian/1.3.1-1 X-Accept-Language: en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: [RFC] TARGET_CHAR_BIT != HOST_CHAR_BIT Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00409.txt.bz2 Hi, To be able to port the tic4x target, I am forced to take action towards supporting TARGET_CHAR_BIT != 8 and TARGET_CHAR_BIT != HOST_CHAR_BIT. (TARGET_CHAR_BIT is 32 on this specific target.) First up for me is the load_section_callback() function in symfile.c - it handles the "load" command when doing remote debugging. It downloads x bytes to the target, and then increases the lma by x. Since TARGET_CHAR_BIT != HOST_CHAR_BIT this isnt correct. The simplest way to fix this issue (more or less globally) would be to declare a macro or function, target_addr_increase_from_buffersize(), or something, that calculates the lma increase from x with the aid of TARGET_CHAR_BIT (and TARGET_HOST_BIT). We need to make a decision of how to approach this issue. I will still keep porting the tic4x port in my local sandbox, and make this work for me. But as it requires me to make global adaptations, I would surely like to do this with the blessing of the community. 1) IMHO can assume that TARGET_CHAR_BIT and HOST_CHAR_BIT are multiplum of 8. I havn't seen _any_ targets yet that break with this rule. 2) How should we incorporate these macros/function in regards of the gdbarch model? Maby we should make an own gdbarch "attribute" that the targets can define. 3) We need to hunt and track down any portions of the gdb code that has issues with this. I can think of several occations where this will be a problem: - All target pointer arithmetics on host, - buffers and structs, etc. Looking briefly at my old tic4x-gdb patch (pre 5.0), I'd estimate approx. 500 changes to global sources, in over 50 files. Regards, Svein