From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5735 invoked by alias); 12 Sep 2002 14:13:47 -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 5728 invoked from network); 12 Sep 2002 14:13:45 -0000 Received: from unknown (HELO msgbas1.cos.agilent.com) (192.25.240.36) by sources.redhat.com with SMTP; 12 Sep 2002 14:13:45 -0000 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 20F38B7F7; Thu, 12 Sep 2002 08:13:45 -0600 (MDT) Received: from websvr.canada.agilent.com (websvr.canada.agilent.com [141.184.122.102]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 8ACB9369; Thu, 12 Sep 2002 08:13:24 -0600 (MDT) Received: from agilent.com (cos1nai129042.cos.agilent.com [141.184.129.42]) by websvr.canada.agilent.com (8.9.3 (PHNE_25183)/8.9.3 SMKit7.1.1_Agilent) with ESMTP id HAA18066; Thu, 12 Sep 2002 07:13:40 -0700 (PDT) Message-ID: <3D80A114.1060809@agilent.com> Date: Thu, 12 Sep 2002 07:13:00 -0000 From: Earl Chew Organization: Agilent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com, ac131313@ges.redhat.com, jtc@redback.com Subject: Broken remote protocol qOffsets response handling Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00110.txt.bz2 I started using qOffsets, and was dismayed to find that gdb remote.c silently discards bss, and uses data twice instead. Looking through the archives, I see that jtc has already posted a patch to resolve this issue (both in remote.c and nlm/gdbserve.c). http://sources.redhat.com/ml/gdb-patches/1999-q4/msg00011.html Apparently nlm/gdbserve.c is the root of the problem (.bss and .data equivalent), and the hack in remote.c basically makes qOffsets useless for most every other target that could use it. Is it simply too difficult to incorporate this patch? If we can't, I'd propose adding qSections (exactly the same syntax as qOffsets) that doesn't have this inflexible behaviour. Earl