gem5/src/arch/sparc/remote_gdb.hh

104 lines
3.4 KiB
C++
Raw Normal View History

/*
arm: remote GDB: rationalize structure of register offsets Currently, the wire format of register values in g- and G-packets is modelled using a union of uint8/16/32/64 arrays. The offset positions of each register are expressed as a "register count" scaled according to the width of the register in question. This results in counter- intuitive and error-prone "register count arithmetic", and some formats would even be altogether unrepresentable in such model, e.g. a 64-bit register following a 32-bit one would have a fractional index in the regs64 array. Another difficulty is that the array is allocated before the actual architecture of the workload is known (and therefore before the correct size for the array can be calculated). With this patch I propose a simpler mechanism for expressing the register set structure. In the new code, GdbRegCache is an abstract class; its subclasses contain straightforward structs reflecting the register representation. The determination whether to use e.g. the AArch32 vs. AArch64 register set (or SPARCv8 vs SPARCv9, etc.) is made by polymorphically dispatching getregs() to the concrete subclass. The subclass is not instantiated until it is needed for actual g-/G-packet processing, when the mode is already known. This patch is not meant to be merged in on its own, because it changes the contract between src/base/remote_gdb.* and src/arch/*/remote_gdb.*, so as it stands right now, it would break the other architectures. In this patch only the base and the ARM code are provided for review; once we agree on the structure, I will provide src/arch/*/remote_gdb.* for the other architectures; those patches could then be merged in together. Review Request: http://reviews.gem5.org/r/3207/ Pushed by Joel Hestness <jthestness@gmail.com>
2015-12-18 22:12:07 +01:00
* Copyright (c) 2015 LabWare
* Copyright (c) 2002-2005 The Regents of The University of Michigan
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are
* met: redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer;
* redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution;
* neither the name of the copyright holders nor the names of its
* contributors may be used to endorse or promote products derived from
* this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* Authors: Nathan Binkert
arm: remote GDB: rationalize structure of register offsets Currently, the wire format of register values in g- and G-packets is modelled using a union of uint8/16/32/64 arrays. The offset positions of each register are expressed as a "register count" scaled according to the width of the register in question. This results in counter- intuitive and error-prone "register count arithmetic", and some formats would even be altogether unrepresentable in such model, e.g. a 64-bit register following a 32-bit one would have a fractional index in the regs64 array. Another difficulty is that the array is allocated before the actual architecture of the workload is known (and therefore before the correct size for the array can be calculated). With this patch I propose a simpler mechanism for expressing the register set structure. In the new code, GdbRegCache is an abstract class; its subclasses contain straightforward structs reflecting the register representation. The determination whether to use e.g. the AArch32 vs. AArch64 register set (or SPARCv8 vs SPARCv9, etc.) is made by polymorphically dispatching getregs() to the concrete subclass. The subclass is not instantiated until it is needed for actual g-/G-packet processing, when the mode is already known. This patch is not meant to be merged in on its own, because it changes the contract between src/base/remote_gdb.* and src/arch/*/remote_gdb.*, so as it stands right now, it would break the other architectures. In this patch only the base and the ARM code are provided for review; once we agree on the structure, I will provide src/arch/*/remote_gdb.* for the other architectures; those patches could then be merged in together. Review Request: http://reviews.gem5.org/r/3207/ Pushed by Joel Hestness <jthestness@gmail.com>
2015-12-18 22:12:07 +01:00
* Boris Shingarov
*/
#ifndef __ARCH_SPARC_REMOTE_GDB_HH__
#define __ARCH_SPARC_REMOTE_GDB_HH__
#include <map>
#include "base/remote_gdb.hh"
class System;
class ThreadContext;
namespace SparcISA
{
class RemoteGDB : public BaseRemoteGDB
{
protected:
arm: remote GDB: rationalize structure of register offsets Currently, the wire format of register values in g- and G-packets is modelled using a union of uint8/16/32/64 arrays. The offset positions of each register are expressed as a "register count" scaled according to the width of the register in question. This results in counter- intuitive and error-prone "register count arithmetic", and some formats would even be altogether unrepresentable in such model, e.g. a 64-bit register following a 32-bit one would have a fractional index in the regs64 array. Another difficulty is that the array is allocated before the actual architecture of the workload is known (and therefore before the correct size for the array can be calculated). With this patch I propose a simpler mechanism for expressing the register set structure. In the new code, GdbRegCache is an abstract class; its subclasses contain straightforward structs reflecting the register representation. The determination whether to use e.g. the AArch32 vs. AArch64 register set (or SPARCv8 vs SPARCv9, etc.) is made by polymorphically dispatching getregs() to the concrete subclass. The subclass is not instantiated until it is needed for actual g-/G-packet processing, when the mode is already known. This patch is not meant to be merged in on its own, because it changes the contract between src/base/remote_gdb.* and src/arch/*/remote_gdb.*, so as it stands right now, it would break the other architectures. In this patch only the base and the ARM code are provided for review; once we agree on the structure, I will provide src/arch/*/remote_gdb.* for the other architectures; those patches could then be merged in together. Review Request: http://reviews.gem5.org/r/3207/ Pushed by Joel Hestness <jthestness@gmail.com>
2015-12-18 22:12:07 +01:00
bool acc(Addr addr, size_t len);
class SPARCGdbRegCache : public BaseGdbRegCache
{
arm: remote GDB: rationalize structure of register offsets Currently, the wire format of register values in g- and G-packets is modelled using a union of uint8/16/32/64 arrays. The offset positions of each register are expressed as a "register count" scaled according to the width of the register in question. This results in counter- intuitive and error-prone "register count arithmetic", and some formats would even be altogether unrepresentable in such model, e.g. a 64-bit register following a 32-bit one would have a fractional index in the regs64 array. Another difficulty is that the array is allocated before the actual architecture of the workload is known (and therefore before the correct size for the array can be calculated). With this patch I propose a simpler mechanism for expressing the register set structure. In the new code, GdbRegCache is an abstract class; its subclasses contain straightforward structs reflecting the register representation. The determination whether to use e.g. the AArch32 vs. AArch64 register set (or SPARCv8 vs SPARCv9, etc.) is made by polymorphically dispatching getregs() to the concrete subclass. The subclass is not instantiated until it is needed for actual g-/G-packet processing, when the mode is already known. This patch is not meant to be merged in on its own, because it changes the contract between src/base/remote_gdb.* and src/arch/*/remote_gdb.*, so as it stands right now, it would break the other architectures. In this patch only the base and the ARM code are provided for review; once we agree on the structure, I will provide src/arch/*/remote_gdb.* for the other architectures; those patches could then be merged in together. Review Request: http://reviews.gem5.org/r/3207/ Pushed by Joel Hestness <jthestness@gmail.com>
2015-12-18 22:12:07 +01:00
using BaseGdbRegCache::BaseGdbRegCache;
private:
struct {
uint32_t gpr[32];
uint32_t hole[32];
uint32_t y;
uint32_t psr;
uint32_t wim;
uint32_t tbr;
uint32_t pc;
uint32_t npc;
uint32_t fsr;
uint32_t csr;
} r;
public:
char *data() const { return (char *)&r; }
size_t size() const { return sizeof(r); }
void getRegs(ThreadContext*);
void setRegs(ThreadContext*) const;
const std::string name() const { return gdb->name() + ".SPARCGdbRegCache"; }
};
arm: remote GDB: rationalize structure of register offsets Currently, the wire format of register values in g- and G-packets is modelled using a union of uint8/16/32/64 arrays. The offset positions of each register are expressed as a "register count" scaled according to the width of the register in question. This results in counter- intuitive and error-prone "register count arithmetic", and some formats would even be altogether unrepresentable in such model, e.g. a 64-bit register following a 32-bit one would have a fractional index in the regs64 array. Another difficulty is that the array is allocated before the actual architecture of the workload is known (and therefore before the correct size for the array can be calculated). With this patch I propose a simpler mechanism for expressing the register set structure. In the new code, GdbRegCache is an abstract class; its subclasses contain straightforward structs reflecting the register representation. The determination whether to use e.g. the AArch32 vs. AArch64 register set (or SPARCv8 vs SPARCv9, etc.) is made by polymorphically dispatching getregs() to the concrete subclass. The subclass is not instantiated until it is needed for actual g-/G-packet processing, when the mode is already known. This patch is not meant to be merged in on its own, because it changes the contract between src/base/remote_gdb.* and src/arch/*/remote_gdb.*, so as it stands right now, it would break the other architectures. In this patch only the base and the ARM code are provided for review; once we agree on the structure, I will provide src/arch/*/remote_gdb.* for the other architectures; those patches could then be merged in together. Review Request: http://reviews.gem5.org/r/3207/ Pushed by Joel Hestness <jthestness@gmail.com>
2015-12-18 22:12:07 +01:00
class SPARC64GdbRegCache : public BaseGdbRegCache
{
using BaseGdbRegCache::BaseGdbRegCache;
private:
struct {
uint64_t gpr[32];
uint64_t fpr[32];
uint64_t pc;
uint64_t npc;
uint64_t state;
uint64_t fsr;
uint64_t fprs;
uint64_t y;
} r;
public:
char *data() const { return (char *)&r; }
size_t size() const { return sizeof(r); }
void getRegs(ThreadContext*);
void setRegs(ThreadContext*) const;
const std::string name() const { return gdb->name() + ".SPARC64GdbRegCache"; }
};
arm: remote GDB: rationalize structure of register offsets Currently, the wire format of register values in g- and G-packets is modelled using a union of uint8/16/32/64 arrays. The offset positions of each register are expressed as a "register count" scaled according to the width of the register in question. This results in counter- intuitive and error-prone "register count arithmetic", and some formats would even be altogether unrepresentable in such model, e.g. a 64-bit register following a 32-bit one would have a fractional index in the regs64 array. Another difficulty is that the array is allocated before the actual architecture of the workload is known (and therefore before the correct size for the array can be calculated). With this patch I propose a simpler mechanism for expressing the register set structure. In the new code, GdbRegCache is an abstract class; its subclasses contain straightforward structs reflecting the register representation. The determination whether to use e.g. the AArch32 vs. AArch64 register set (or SPARCv8 vs SPARCv9, etc.) is made by polymorphically dispatching getregs() to the concrete subclass. The subclass is not instantiated until it is needed for actual g-/G-packet processing, when the mode is already known. This patch is not meant to be merged in on its own, because it changes the contract between src/base/remote_gdb.* and src/arch/*/remote_gdb.*, so as it stands right now, it would break the other architectures. In this patch only the base and the ARM code are provided for review; once we agree on the structure, I will provide src/arch/*/remote_gdb.* for the other architectures; those patches could then be merged in together. Review Request: http://reviews.gem5.org/r/3207/ Pushed by Joel Hestness <jthestness@gmail.com>
2015-12-18 22:12:07 +01:00
public:
RemoteGDB(System *_system, ThreadContext *tc);
BaseGdbRegCache *gdbRegs();
};
arm: remote GDB: rationalize structure of register offsets Currently, the wire format of register values in g- and G-packets is modelled using a union of uint8/16/32/64 arrays. The offset positions of each register are expressed as a "register count" scaled according to the width of the register in question. This results in counter- intuitive and error-prone "register count arithmetic", and some formats would even be altogether unrepresentable in such model, e.g. a 64-bit register following a 32-bit one would have a fractional index in the regs64 array. Another difficulty is that the array is allocated before the actual architecture of the workload is known (and therefore before the correct size for the array can be calculated). With this patch I propose a simpler mechanism for expressing the register set structure. In the new code, GdbRegCache is an abstract class; its subclasses contain straightforward structs reflecting the register representation. The determination whether to use e.g. the AArch32 vs. AArch64 register set (or SPARCv8 vs SPARCv9, etc.) is made by polymorphically dispatching getregs() to the concrete subclass. The subclass is not instantiated until it is needed for actual g-/G-packet processing, when the mode is already known. This patch is not meant to be merged in on its own, because it changes the contract between src/base/remote_gdb.* and src/arch/*/remote_gdb.*, so as it stands right now, it would break the other architectures. In this patch only the base and the ARM code are provided for review; once we agree on the structure, I will provide src/arch/*/remote_gdb.* for the other architectures; those patches could then be merged in together. Review Request: http://reviews.gem5.org/r/3207/ Pushed by Joel Hestness <jthestness@gmail.com>
2015-12-18 22:12:07 +01:00
} // namespace SparcISA
#endif /* __ARCH_SPARC_REMOTE_GDB_H__ */