[Libre-soc-bugs] [Bug 1226] New: are special_sprs tests in caller.py backwards?

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Thu Nov 30 10:46:35 GMT 2023


https://bugs.libre-soc.org/show_bug.cgi?id=1226

            Bug ID: 1226
           Summary: are special_sprs tests in caller.py backwards?
           Product: Libre-SOC's first SoC
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: CONFIRMED
          Severity: minor
          Priority: ---
         Component: Source Code
          Assignee: lkcl at lkcl.net
          Reporter: programmerjake at gmail.com
                CC: libre-soc-bugs at lists.libre-soc.org
   NLnet milestone: ---

there's several different places where ISACaller tries to read/write SPRs and
specially handle some SPRs using special_sprs:
e.g. when reading insn inputs:

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/caller.py;hb=2eb5abb845808c436797f3a5449f847fefdacca8#l2236

2236         for special in info.special_regs:
2237             if special in special_sprs:
2238                 inputs[special] = self.spr[special]
2239             else:
2240                 inputs[special] = self.namespace[special]

note the `if special in special_sprs: use self.spr else: use self.namespace`

that looks backwards to me, shouldn't the special SPRs be kept in namespace and
all the rest in self.spr?!

This causes a problem when running emulated sc without initializing SRR0 (I
didn't initialize it cuz we're user space, who cares what value a register we
can't access has):

        # "special" registers
        for special in info.special_regs:
            if special in special_sprs:
                inputs[special] = self.spr[special]
            else:
>               inputs[special] = self.namespace[special]
E               KeyError: 'SRR0'

if the code had instead tried to access self.spr['SRR0'], then SPR.__getitem__
would have filled in a default value rather than failing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the libre-soc-bugs mailing list