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

[John Crispin]

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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>