From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) by sourceware.org (Postfix) with ESMTPS id 4B11A385BF83 for ; Mon, 13 Apr 2020 13:04:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4B11A385BF83 Received: by mail-qv1-xf2b.google.com with SMTP id w26so4269267qvd.10 for ; Mon, 13 Apr 2020 06:04:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NNP8Kl1nZtBGE6uk2B5xNpwkPXL6iuv41//JEV2EvDQ=; b=k7J4YTI1/hdtUiad6q1TIOu96QXS/pcrBCB3fM3k00fpaPXxY0JTy5OVf1S8N3Rn8X JuUG4mQZkI2el4enchNbGsh6hAYQy3bdBiwoFN2z+cm6pyrm6vf5lcu08+1ZiNKNoCqW RKdzDDROmXnLeTxrCzqgeSraHvhcluz0Qw9oQxmIT8u0H2RbIEfCX4xzrX43Kj917cXB T+b2awDG5FxkFzRC7/U9HeZtxUqmo3L0395/0DacdlclxrBMXYB+Plg/Juvm+xVck7BV 356wfMPz0reolwSiY5jy6watctxg/Ww/bS5YXbaKb9W5qij/xtrwTlx/xsGuLx4YBjGd tLqg== X-Gm-Message-State: AGi0PuaIKh2WyZC5Bx7USr1FcvqeXL111AYgUhbzVDt3RSvHlNHsgQ2E hQehtsd146+88dHzfYq8AgBuLZZdJHw= X-Google-Smtp-Source: APiQypJyOwydWe0l0puh944kFpjXVVJPgPZtRZuWj7uS126+fdVJfCPn4iIqkSOqEmI8fVdVHrND+g== X-Received: by 2002:a0c:b661:: with SMTP id q33mr16467976qvf.190.1586783074231; Mon, 13 Apr 2020 06:04:34 -0700 (PDT) Received: from [192.168.0.181] ([191.249.229.71]) by smtp.gmail.com with ESMTPSA id i18sm8021268qtp.8.2020.04.13.06.04.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Apr 2020 06:04:33 -0700 (PDT) Subject: Re: Specifying target endianness via Remote Serial Protocol To: Omer , gdb@sourceware.org References: From: Luis Machado Message-ID: Date: Mon, 13 Apr 2020 10:04:30 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 13:04:36 -0000 Hi, On 4/12/20 9:02 AM, Omer via Gdb wrote: > Hi, > > While writing my own gdb stub, I noticed that there is no way to specify > what endianness the target is using (I guess the logical place for that > would be in the target.xml file). > One can use "set endian" manually to fix that, but when debugging an ARM > BE8 target, there is no way to specify that the code is little endian > (currently byte_order_for_code is initialized to little only when loading a > BE8 elf). > Shouldn't there be an additional field for target XML tag to specify that? We could probably extend the XML descriptions to incorporate this, but we may also have backwards compatibility issues with older GDB's by returning new fields the target doesn't know how to parse properly. The way to fix this, right now, would be to teach GDB about other arch variations using little endian, so GDB initializes the proper set of architecture hooks and types. What arch variation are you working with? Doesn't the tools generate a EF_ARM_BE8 flag to let GDB know it needs to assume little endian?