[LEDE-DEV] [PATCH] package/devel/gdb: Add support of ARC gdb

[Alexey Brodkin]

Hi John,

On Fri, 2016-06-03 at 11:09 +0200, John Crispin wrote:
> Hi,
> 
> On 01/06/2016 17:32, Alexey Brodkin wrote:
> > 
> > As of today gdb port for ARC is not yet in upstream even though
> > we're working hard on that.
> > 
> > Still to allow ARC users to debug user-space apps on top of
> > Linux kernel we're adding here support for building GDB from
> > sources hosted on our GitHub here:
> > https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/releases/tag/arc-2016.03-gdb
> > 
> > Likewise for host GDB sources that come from unified git repository
> > (which is the case for upstream binutils/gdb today) we need to disable
> > building of binutils in gdb:
> > ------>8------
> > --disable-binutils
> > --disable-ld
> > --disable-gas
> > ------>8------
> > 
> these work for !arc targets. disabling them for all targets because they
> are broken on arc seem weird even if they might not be used.
> 
> rather than cluttering the makefile how about marking the packahe broken
> for arc and adding a new one called gdb-arc that depends on arc only.
> this will allow us to keep gdb clean and just drop the gdb-arc package
> once the fixes treacled down the tree.

Well all 3 options except "--sim" are very valid because modern GDB sources
come from "unified" git repo where binutils co-exist with gdb.

That's done on purpose because a lot of stuff indeed is the same in both
projects. And there's really no point in building either binutils, ld or gas
when we're building GDB. Disabling those options we at least saving some time
and in some cases may escape build failures.

Mentioned build failures might happen with some even release versions of GDB
tarballs. Again that is because gdb comes from the same unified repo BUT
(and that's important) still from the separate branch and so some parts of
binutils might be taken from "binutils" branch in unstable state.

In other words disabling build of not used components is pretty safe and
future-proof. And simulator falls here as well - we don't need it anyways
for either arch/board.

As for adding a separate package... we'll need to propagate new Kconfig symbol in
other files and so instead of limiting changes to 1 file we'll spread our
contamination all over source tree. Do we really want it?

-Alexey