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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
