Fw: Fw: Any plans to integrate just binutils ‑gdb into GCC?

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: unlvsur unlvsur <[email protected]>
Sent: Thursday, 23 July 2026 10:49:49
To: Segher Boessenkool <[email protected]>; Michael Clark <[email protected]>
Subject: Re: Fw: Any plans to integrate just binutils‑gdb into GCC?

i know you can manually put two repo together. What i am talking about is a broader software engineering issue.


  1.
Two repos need to support each other with different versions.
Since GCC and binutils-gdb are currently two projects, GCC needs to support old versions of binutils-gdb and binutils-gdb needs to support old versions of GCC. Compared to LLVM, they only need to support the current version of itself, this is a huge headache for maintainence.
  2.
Hard to make changes across both binutils-gdb and GCC. And this has been proven that LLVM now makes changes much faster than GCC for adding features. There are many other reasons why LLVM moves faster (such as cross compiling does not need a seperate $target-gcc ), however, that is an important one.
  3.
Confusing. People often only build cross compilers for binutils-gdb, when they often need to build it for native compilers too.
  4.
Hard for binutils-gdb and gcc to use latest C++ version compared to LLVM.
  5.
LLVM provides much more tools than binutils-gdb + GCC combines. Without putting them together, a lot of tools are simply impossible.
  6.
Lack of important modern targets support for gcc/binutils-gdb. No android, no windows on arm, no mac, no wasm. One reason is exactly they need to submit mailing patches to both of them, that is extremely annoying and often breaks things across projects

I think merging binutils-gdb under the umbrella of GCC is important for GCC to move forward and competes with LLVM. Also the vibe coding gives GCC an opportunity to clean up the mess of build/host/target combos and make gcc to support --target=triplet --sysroot=sysroot easily compared to ever before.

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Segher Boessenkool <[email protected]>
Sent: Wednesday, 22 July 2026 20:50:49
To: Michael Clark <[email protected]>
Cc: unlvsur unlvsur <[email protected]>
Subject: Re: Fw: Any plans to integrate just binutils‑gdb into GCC?

On Thu, Jul 23, 2026 at 12:35:34AM +1200, Michael Clark wrote:
> On 7/22/26 22:46, Segher Boessenkool wrote:
> > GDB is completely unrelated to GCC -- it can attach to *any* executable,
> > whether compiled using GCC or not, whether compiled *at all* or not!
> >
> > binutils and GCC have always been set up so they work well together,
> > designed with the other in mind.
> >
> > But the two projects are separate, and this is a good thing, nothing
> > will be won by forcing them together, and much can be lost.
> >
> > What LLVM did is to have the compiler not generate assembly language,
> > but an object file directly.  This is a terrible idea.  Throwing away a
> > lot of flexibility, for essentially no benefit at all.  Except when you
> > think abandoning the way things have always been done is a good idea,
> > heh.  Revolutionaries!
>
> is that really what LLVM does? I thought it had an assembly streamer.

That disassembles the generated machine code, and combines that with
other LLVM internal data (to get at the CFI info for example), to make a
halfhearted approximation to the proper way to do things.

> tokenizing assembler should make compiles faster but one might want
> the front part of the assembler in the compiler so that it can use
> the same tokens as the assembler uses. otherwise trickier to do.

I have no idea what you mean to say here, sorry.  The slowest part of
the assembler typically is looking up the mnemonics.  Usually adding a
cache speeds things up 1000x or so.  Been there, done that.  It never
makes things much better on a real-world scale, it never annoyed people
enough to speed up their target code in the first place!


Segher