From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-45368-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 52783 invoked by alias); 11 Oct 2016 14:30:31 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Received: (qmail 39576 invoked by uid 89); 11 Oct 2016 14:30:26 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=Question, H*r:10.0.0, H*RU:sk:p3plsmt, Hx-spam-relays-external:sk:p3plsmt
X-HELO: p3plsmtpa06-05.prod.phx3.secureserver.net
Received: from p3plsmtpa06-05.prod.phx3.secureserver.net (HELO p3plsmtpa06-05.prod.phx3.secureserver.net) (173.201.192.106) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Oct 2016 14:30:25 +0000
Received: from [10.0.0.101] ([172.14.36.47])	by :SMTPAUTH: with SMTP	id ty3wbuHCYedSEty3xbW6PU; Tue, 11 Oct 2016 07:29:49 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: can target code change architecture setting?
From: Duane Ellis <duane@duaneellis.com>
In-Reply-To: <CAH=s-PMXhOcr5EhK0RShxqgurtV99NHvgBUOBWZocmkMttoCLg@mail.gmail.com>
Date: Tue, 11 Oct 2016 14:30:00 -0000
Cc: Tim Newsome <tim@sifive.com>, gdb <gdb@sourceware.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA6120EE-A298-4B95-B037-C461A3443561@duaneellis.com>
References: <20161010094844.5c1bb9f86d671edec44bb378f25c04cc.aef8a9655c.wbe@email03.godaddy.com> <CAH=s-PMXhOcr5EhK0RShxqgurtV99NHvgBUOBWZocmkMttoCLg@mail.gmail.com>
To: Yao Qi <qiyaoltc@gmail.com>
X-CMAE-Envelope: MS4wfBTrn/gZW2Y9AhfDKZB9m9nqzg9im2mwGaCbg0fWnbDYCKy667KLV5MeQMEmNBiSuo2OUvp+7XwmKBd7nvSeJOdMMcymJFfVi2ymBs7o+p1X9ZjTn/HH i7e2REtZegY9z1tkTuaOT7vwcA+l1JT8JKuuAtfJGdLOsoS7wmu3NntwzdJSSJ/hNJibOHvW/3k8IK2H0jIdoLW2Keloe9rjKJ/Rjh62LD9t2bssKXNDYA5X
X-IsSubscribed: yes
X-SW-Source: 2016-10/txt/msg00021.txt.bz2

>=20
>> Question #2 - How should the remote debugger respond to GDB?
>>=20
>>      I don't think there is an "architecture change" packet.
>>=20
>=20
> 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 de=
bug (i.e.: dwarf) information.

In bare metal - You don=E2=80=99t always have this, you might have *labels*=
 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* ar=
ch.

Or the target needs to send a =E2=80=9Ctarget-arch-change-indication=E2=80=
=9D in some way.

-Duane.