From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15102 invoked by alias); 3 Nov 2016 19:47:09 -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 15086 invoked by uid 89); 3 Nov 2016 19:47:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=ellis, Ellis, pc, duane X-HELO: mail-wm0-f44.google.com Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 03 Nov 2016 19:46:58 +0000 Received: by mail-wm0-f44.google.com with SMTP id p190so8577387wmp.1 for ; Thu, 03 Nov 2016 12:46:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=v71JLpIXOVoY8sLGbP2GvcPDdKMTm3RqFeMUQJgwphE=; b=gDaTOfA1bau3PsKTqtBGmMe8tbIK0dYhdyNY0nllNagC0YSeBi/iJUU2W4Ga8bx4lv wAtTvywt4SBGNLB7/ITKvHgDZYTtrnNRaKOy73b/GavhAFIfHNYuIiJHBvDckcpnw4qW BbMZ1AMr9JtFn5+jOjOl3h6uheCTwlsbVD4YRj4kYo5rSqFxcxliqNb0NiD22s5VLfcv 6mlscnEpVLlBqJ3SUeepHcaVT1kN0f96Nlf/ylY2slii36wtsF9yFk8IsfRmBp9iQIDq +dBAhG7JZqv5UIfIF7w5Sm0UGNo+yyPsQc6mpFC3u3fHRjHU2vxBw0gxZV86iyRQseTf 4szw== X-Gm-Message-State: ABUngvf1U4R18bJ8LZCUry9CNbAl+bEdMc4lv+MqXICaaJb5+XUI/UwbzPYwI0YkE1M5V/6ffLI+jnZnQ5tMyaWV X-Received: by 10.194.189.198 with SMTP id gk6mr8733126wjc.167.1478202415913; Thu, 03 Nov 2016 12:46:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.152.70 with HTTP; Thu, 3 Nov 2016 12:46:15 -0700 (PDT) In-Reply-To: References: <20161010094844.5c1bb9f86d671edec44bb378f25c04cc.aef8a9655c.wbe@email03.godaddy.com> From: Doug Evans Date: Thu, 03 Nov 2016 19:47:00 -0000 Message-ID: Subject: Re: can target code change architecture setting? To: Duane Ellis Cc: Yao Qi , Tim Newsome , gdb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00003.txt.bz2 On Tue, Oct 11, 2016 at 7:29 AM, Duane Ellis wrote: >> >>> Question #2 - How should the remote debugger respond to GDB? >>> >>> I don't think there is an "architecture change" packet. >>> >> >> Such packet is not needed, because GDB has to determine the gdbarch >> of each when unwinding. > > I think you are making the assumption that GDB always has access to full = debug (i.e.: dwarf) information. > > In bare metal - You don=E2=80=99t always have this, you might have *label= s* only (function name vrs address) but no source, no dwarf information. > > The only solution is to *ask* the target =E2=80=9Cwhat is your *current* = arch. > > Or the target needs to send a =E2=80=9Ctarget-arch-change-indication=E2= =80=9D in some way. Agreed. Consider booting some x86 kernel on qemu (e.g., passing -s -S to qemu). At the start $pc is at the x86 reset location and the architecture is 16-bi= t. (gdb) tar ext :1234 Remote debugging using :1234 0x000000000000fff0 in ?? () At some later point the o/s will switch to 32 or 64-bit mode but until then gdb isn't as useful as one might want it to be.