[GDB] Read the BCR register for determining CPU version

[shahab-vahedi]

Found in issue. See the comment.

GDB sets disassembly options incorrectly based on insufficient data. It needs the following register to determine the CPU (and hence the correct disassembly option):

micro_arch_build

This probably means that the support for the BCR register has to be added to ptrace and then GDB should ask the remote stub for this value. The remote stub can be GDBserver, or QEMU and nSIM themselves in case of a baremetal application.

[vineetgarc]

ptrace is an ABI change so you need to have a pairing kernel which adds that (and typically backports of those things are not allowed). Moreover it is likely this reg is readable from user space. So assuming that is not considered evil in gdb land (i.e. using arch specific regs vs. ptrace) this can be done in gdb itself (please double check with hw folks about the claim since the PRM doesn't clearly say if it is priv mode only.

[anthony-kolesov]

This register has permission R meaning that read from user is privilege violation:

However, in user mode, reads from build configuration registers always raise a Privilege Violation
exception (see Privilege Violation, Kernel Only Access).

I think another way to address this is to expose values of BCR as byte array in /dev/ or /proc. Address space for BCRs is fixed, kernel-space reads are RAZ, and registers are immutable, so kernel can just read BCRs wit lr() in a loop once and expose the read result as-is. The application (gdbserver in this case) will just have to translate indices inside of array into AUX numbers 0x60-0x7F and 0xC0-0xFF. Alternative approach is to parse data in the kernel and expose as a text file in a form like MICRO_ARCH_BUILD=0x1 , but this will be more difficult to parse in gdbserver.

And if there is a desire to limit amount of BCRs exposed to the user-space, then this approach can still be implemented, but only necessary registers would be read (like ISA_CONFIG, MICRO_ARCH_BUILD), while the rest will be shown as 0 regardless of values in the hardware. Then registers could be added as necessary replacing 0 with a valid value. This will be both forward and backward compatible for applications that try to use this array - gdbserver may try to use values of any BCR present, but kernel will expose only some of them. Then newer versions of kernel will expose new BCRs and old gdbserver would start work like a magic. Similarly a new gdbserver could still work on an older kernel - it would just get less information from it. And if file is not available then gdbserver can treat it as all BCRs are 0 - potentially falling back to some other mechanism if needed.

[vineetgarc]

Good points Anton. Mechanics aside (ptrace, /proc or /sysfs, binary or strings) this still has ABI implication in long term maintenance. We've seen quite a few times non-compatible hw changes being made (aux address changes, layout changes, aux just added or removed) which will be hard to track/version control in downstream software like gdb. So best to implement a minimal interface in gdb. Or we can also look at implement glibc hwcaps which some other arches do to expose this in a more standardized manner. Anyways something to think through before rushing an implication as this is equivalent to marriage for life with no option of divorce.

[anthony-kolesov]

You also can consider using LLDB's register database to implement the BCR value handling logic. The database contains information about which BCR has what name, address, and fields. And then individual registers has python expressions of form

AGU_BUILD.VERSION == 3 and AGU_BUILD.NUM_ADDR > 3

for a AGU_AUX_AP3 for example. I already now how to translate this Python expression into a TCL expression for OpenOCD, for example, so it would be possible to generate C expression from that as well. Then we can define a "capability" file in the register database that will describe a list of desired capabilities which will look like this:

is_arc_em = micro_arch_build.product == 0x1
is_arc_hs3x = micro_arch_build.product == 0x3
is_arc_hs4x = micro_arch_build.product == 0x4
has_hw_loops = isa_config.version == 2 and isa_config.lpc_size > 0 

That will generate something like this:

typedef std::map<std::string, uint64_t> RegisterFieldValues; // field_name -> field_value
typedef std::map<std::string, RegisterFieldValues> BcrValues; // BCR name -> field values

bool
has_hw_loops_capability(const BcrValues& bcrValues)
{
    return bcrValues["isa_config"]["version"] == 2 && bcrValues["isa_config"]["lpc_size "] > 0;
}

There is of course a non-trivial amount of code to actually generate those value mappings from raw values, but this is a kind-of a solved task in Python code for LLDB, so could be ported to C++ and GDB. Of course all of that makes sense only if there will be a goal to provide many capabilities. Doing all of this gymnastics just for a few register values would be an overkill.

[shahab-vahedi]

@anthony-kolesov I am very pleased to know that all the logic of capabilities are gathered in our LLDB port. That means when I want to make use some of those in GDB, I don't have to scavenge them through the pages of Databook/PRM. About using the database directly in GDB (through code generation) I don't find it beneficial for the few use cases that GDB has.

@vineetgarc I agree with you that we have to think this through before we make any move. The outcome should:

1. be sensible
2. be extendable
3. not look like a compromise or hack on either side of kernel or GDB(server).

@anthony-kolesov I think your proposal of having a map in /proc is very out of the box and something worth of mulling over during the course of discussions.

I, for one, have to do my homework and see how other targets handle these cases.

[anthony-kolesov]

As a note, at request of one of the teams I've added a capability to the register database to generate C header files with info about the AUX registers which look like this:

    /* Core Identity Register */
    #define ARC_AUX_IDENTITY (0x4)
        /* ARC baseline instruction set version number */
        #define ARC_AUX_IDENTITY_ARCVER(r) ((r & 0xff) >> 0)
    
        /* Unique identifier of each core in a multi-core system. */
        #define ARC_AUX_IDENTITY_ARCNUM(r) ((r & 0xffff) >> 8)
    
        /* Deprecated field */
        #define ARC_AUX_IDENTITY_CHIPID(r) ((r & 0xffffffff) >> 16)

[shahab-vahedi]

For the record, @vineetgarc was talking about these types of object attributes:

$ arc-elf32-readelf -a test.exe
...
No version information found in this file.
Attribute Section: ARC
File Attributes
  Tag_ARC_CPU_base: ARCHS
  Tag_ARC_CPU_name: "archs"
  Tag_ARC_ABI_osver: v4
  Tag_ARC_ISA_config: "CD"
  Tag_ARC_ATR_version: 1

I think the wise move is to consider this alternative instead of implementing the BCR reading.