On 03/06/2016 16:46, Alexey Brodkin wrote: > 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?
which packages depend on gdbserver ? > > -Alexey > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
