1. 15 Mar, 2019 4 commits
    • Dimitri A's avatar
      gdbstub: Fix some bugs in IsMemoryBreak() and ServeBreak. Add workaround to... · 0e7ad1c3
      Dimitri A authored
      gdbstub: Fix some bugs in IsMemoryBreak() and ServeBreak. Add workaround to let watchpoints break into GDB. (#4651)
      
      * gdbstub: fix IsMemoryBreak() returning false while connected to client
      
      As a result, the only existing codepath for a memory watchpoint hit to break into GDB (InterpeterMainLoop, GDB_BP_CHECK, ARMul_State::RecordBreak) is finally taken,
      which exposes incorrect logic* in both RecordBreak and ServeBreak.
      
      * a blank BreakpointAddress structure is passed, which sets r15 (PC) to NULL
      
      * gdbstub: DynCom: default-initialize two members/vars used in conditionals
      
      * gdbstub: DynCom: don't record memory watchpoint hits via RecordBreak()
      
      For now, instead check for GDBStub::IsMemoryBreak() in InterpreterMainLoop and ServeBreak.
      
      Fixes PC being set to a stale/unhit breakpoint address (often zero) when a memory watchpoint (rwatch, watch, awatch) is handled in ServeBreak() and generates a GDB trap.
      
      Reasons for removing a call to RecordBreak() for memory watchpoints:
      * The``breakpoint_data`` we pass is typed Execute or None. It describes the predicted next code breakpoint hit relative to PC;
      
      * GDBStub::IsMemoryBreak() returns true if a recent Read/Write operation hit a watchpoint. It doesn't specify which in return, nor does it trace it anywhere. Thus, the only data we could give RecordBreak() is a placeholder BreakpointAddress at offset NULL and type Access. I found the idea silly, compared to simply relying on GDBStub::IsMemoryBreak().
      
      There is currently no measure in the code that remembers the addresses (and types) of any watchpoints that were hit by an instruction, in order to send them to GDB as "extended stop information."
      I'm considering an implementation for this.
      
      * gdbstub: Change an ASSERT to DEBUG_ASSERT
      
      I have never seen the (Reg[15] == last_bkpt.address) assert fail in practice, even after several weeks of (locally) developping various branches around GDB.  Only leave it inside Debug builds.
      0e7ad1c3
    • bunnei's avatar
      Merge pull request #2233 from ReinUsesLisp/morton-cleanup · 84d3cdf7
      bunnei authored
      video_core/morton: Miscellaneous changes
      84d3cdf7
    • bunnei's avatar
      Merge pull request #2229 from ReinUsesLisp/vk-sampler-cache · 6788ebff
      bunnei authored
      vk_sampler_cache: Implement a sampler cache
      6788ebff
    • bunnei's avatar
      Merge pull request #2230 from lioncash/global · 2d954684
      bunnei authored
      kernel/process: Remove use of global system accessors
      2d954684
  2. 14 Mar, 2019 1 commit
  3. 13 Mar, 2019 12 commits
  4. 12 Mar, 2019 6 commits
  5. 11 Mar, 2019 4 commits
    • Lioncash's avatar
      renderer_opengl/gl_global_cache: Replace indexing for assignment with insert_or_assign · 3350c0a7
      Lioncash authored
      The previous code had some minor issues with it, really not a big deal,
      but amending it is basically 'free', so I figured, "why not?".
      
      With the standard container maps, when:
      
      map[key] = thing;
      
      is done, this can cause potentially undesirable behavior in certain
      scenarios. In particular, if there's no value associated with the key,
      then the map constructs a default initialized instance of the value
      type.
      
      In this case, since it's a std::shared_ptr (as a type alias) that is
      the value type, this will construct a std::shared_pointer, and then
      assign over it (with objects that are quite large, or actively heap
      allocate this can be extremely undesirable).
      
      We also make the function take the region by value, as we can avoid a
      copy (and by extension with std::shared_ptr, a copy causes an atomic
      reference count increment), in certain scenarios when ownership isn't a
      concern (i.e. when ReserveGlobalRegion is called with an rvalue
      reference, then no copy at all occurs). So, it's more-or-less a "free"
      gain without many downsides.
      3350c0a7
    • Lioncash's avatar
      renderer_opengl/gl_global_cache: Append missing override specifiers · 1070c020
      Lioncash authored
      Two of the functions here are overridden functions, so we can append
      these specifiers to make it explicit.
      1070c020
    • Lioncash's avatar
      kernel/server_port: Make data members private · aa44eb63
      Lioncash authored
      With this, all kernel objects finally have all of their data members
      behind an interface, making it nicer to reason about interactions with
      other code (as external code no longer has the freedom to totally alter
      internals and potentially messing up invariants).
      aa44eb63
    • ReinUsesLisp's avatar
      a6c04892
  6. 10 Mar, 2019 13 commits