Context Around a year and a half ago, I’ve asked my former company for some time to work on an issue that was impacting the debugging capabilities in our project: gdbserver couldn’t debug multithreaded applications running on a PowerPC32 architecture. The connection to the gdbserver was broken and it couldn’t control the debug session anymore. Multiple people have already investigated this problem and I had a good starting point, but we still weren’t sure in which software component the issue lied: it could have been the toolchain, the gdbserver, the Linux kernel or the custom patches we applied on top of the kernel tree. We were quite far away from finding the root cause.
  • @cmeerwEnglish
    25•9 months ago

    Did a bit more digging through the mailing list (also looking through the links posted on the HN thread), and to me it looks a bit weird.

    OP came up with an initial patch (Wed, Jun 1, 2022 at 12:36 PM) that wasn’t deemed to be good enough to be merged. Maintainer came up with a different patch (Tue, 7 Jun 2022 00:34:56 +1000) saying “but I wanted to fix it differently”. OP then posted a reworked patch (Fri Jun 10 17:15:49 AEST 2022) that looks a lot more similar to the maintainer’s patch.

    The maintainer’s patch and OP’s reworked patch look quite similar, but from what I can see from the mailing list, the maintainer actually came up with that approach, and OP didn’t then credit the maintainer in his reworked patch. @[email protected] can you please clarify, what am I missing?

    • @kairosOPEnglish
      3•9 months ago

      Between the initial patch and the maintainer’s patch there was a private conversation between me and the maintainer (I don’t have access to it because I’ve used my work email and since then I switched companies). I posted my reworked patch only for visibility, since by then they have accepted the maintainer’s patch. But I sent the reworked patch in private to the PowerPC maintainer, before sending it to the powerpc mailing list.