Announcement

Collapse
No announcement yet.

Patches Proposed So Microsoft Debuggers Can Deal With GCC-Built MinGW Executables

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Patches Proposed So Microsoft Debuggers Can Deal With GCC-Built MinGW Executables

    Phoronix: Patches Proposed So Microsoft Debuggers Can Deal With GCC-Built MinGW Executables

    Patches have been proposed for the GCC compiler to ultimately allow MinGW Windows executables to be debugged with Microsoft's debuggers...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    So the goal here is to bloat debug binaries for the sake of convincing a greedy, privacy intruding, ultra rich, long term monopoly exploiting, anti-competitive corporation?

    Who could object to that?

    Comment


    • #3
      Originally posted by ddriver View Post
      So the goal here is to bloat debug binaries for the sake of convincing a greedy, privacy intruding, ultra rich, long term monopoly exploiting, anti-competitive corporation?

      Who could object to that?
      Your point is absolutely valid, but I don't see how this, in particular, is harmful to anyone. MinGW Windows executables- correct me if I'm wrong- seem like something only tangentially (if that much!) related to a vast majority of projects, which will go on as if this switch never existed.

      If I had to choose between this change being kept private to Microsoft or included for all in GCC, I'd unhesitatingly pick the latter. The diff also indicates it's small enough to trivially excise, in case the nuclear option has to be exercised someday.

      Comment


      • #4
        Originally posted by fkelava View Post

        Your point is absolutely valid, but I don't see how this, in particular, is harmful to anyone. MinGW Windows executables- correct me if I'm wrong- seem like something only tangentially (if that much!) related to a vast majority of projects, which will go on as if this switch never existed.

        If I had to choose between this change being kept private to Microsoft or included for all in GCC, I'd unhesitatingly pick the latter. The diff also indicates it's small enough to trivially excise, in case the nuclear option has to be exercised someday.
        The was I see it, it can only be a net benefit to be able to debug Wine, Proton, etc with more debuggers like the native Windows tools themselves. Both GDB and Windows telling a dev "well that could be why it's acting fucky" has to be a good thing...Right???

        Comment


        • #5
          Originally posted by fkelava View Post

          Your point is absolutely valid, but I don't see how this, in particular, is harmful to anyone. MinGW Windows executables- correct me if I'm wrong- seem like something only tangentially (if that much!) related to a vast majority of projects, which will go on as if this switch never existed.

          If I had to choose between this change being kept private to Microsoft or included for all in GCC, I'd unhesitatingly pick the latter. The diff also indicates it's small enough to trivially excise, in case the nuclear option has to be exercised someday.
          Most cross compile using mingw or mingw-w. For example the Sailfish SDK is build using that.

          Comment


          • #6
            Originally posted by skeevy420 View Post

            The was I see it, it can only be a net benefit to be able to debug Wine, Proton, etc with more debuggers like the native Windows tools themselves. Both GDB and Windows telling a dev "well that could be why it's acting fucky" has to be a good thing...Right???
            I agree for a couple of reasons:
            • This change, as I understand it, is atomic. Disinterested parties can revert it.
            • It doesn't disadvantage existing non-proprietary formats, or entice you to use PDB instead.
            • It doesn't fuck with your debug binaries if you don't include the switch.
            • The PDB format has had source from the VC++ compiler published under the MIT license. As I understand it, anyone else could've feasibly done the legwork too.
            • It lets people accustomed to using Windows debugging tools get to the bottom of quirks in a meaningful way.
            It doesn't seem harmful at first, second, or hundredth glance. I'm all for it.

            Comment


            • #7
              Originally posted by Thaodan View Post
              Most cross compile using mingw or mingw-w. For example the Sailfish SDK is build using that.
              I didn't know this was the case. Thank you for clueing me in.

              Comment


              • #8
                Originally posted by fkelava View Post
                [/LIST]It doesn't seem harmful at first, second, or hundredth glance. I'm all for it.
                Embrace - done
                Extend - done
                Extinguish - ongoing

                Also, how do you skip so many glances, and what could you be missing along?
                Last edited by ddriver; 21 March 2021, 12:21 PM.

                Comment


                • #9
                  Originally posted by ddriver View Post

                  Embrace - done
                  Extend - done
                  Extinguish - ongoing
                  Right. In general, I'd entertain the idea, but this is about the change that permits GCC to emit PDB debug information. I am decidedly arguing about this change.

                  3. Extinguish: When extensions become a de facto standard [...]
                  The PDB format has had the relevant source from the Visual C++ compiler published six years ago. No source-available shenanigans- it's MIT'd. A format being introduced as an option years after it could have been introduced, with the format itself targeting a specific, targeted subset of situations in which GCC as a whole is used, is rather obviously just another option instead of the next dominant standard. It does not compete with the existing options, devalue them, or disadvantage them.

                  EEE is a valid concern. EEE is something to be wary of. Changes obviously intended to subvert the ecosystem should be fought against bitterly. But it also does not take a huge amount of scrutiny to deduce that not every change invokes EEE. I maintain that this does not.

                  Comment


                  • #10
                    Originally posted by fkelava View Post
                    EEE is a valid concern. EEE is something to be wary of. Changes obviously intended to subvert the ecosystem should be fought against bitterly. But it also does not take a huge amount of scrutiny to deduce that not every change invokes EEE. I maintain that this does not.
                    What matters is the driving intent and the overall direction of the agenda. Even if M$ engages in truly non-harmful discrete contributions, if that is only in the name of gaining trust and traction to conduct harmful actions, it is still ultimately a bad thing.

                    Call me suspicious, but I strongly doubt M$ is driven by an interest, different from continuing its malignant growth and expanding its ability to extract profit from controlling and selectively stifling progress.

                    Need I remind you that the company achieved quite the monopoly on actions most people wouldn't identify as harmful, and even identify as beneficial to them?

                    So maybe the problem is not in the count of glances you make, but that it takes more of an in-depth examination than a superficial momentary glance.
                    Last edited by ddriver; 21 March 2021, 12:41 PM.

                    Comment

                    Working...
                    X