[v2,2/2] package/gdb: add gdb 7.7.1

Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
---
 package/gdb/Config.in.host | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

Dear Cody P Schafer,

I had a fairly similar patch sitting in my patch stack.

On Sun, 11 May 2014 14:11:13 -0700, Cody P Schafer wrote:

> diff --git a/package/gdb/Config.in.host b/package/gdb/Config.in.host
> index e853469..77c5459 100644
> --- a/package/gdb/Config.in.host
> +++ b/package/gdb/Config.in.host
> @@ -19,7 +19,7 @@ choice
>  	depends on !BR2_microblaze
>  	default BR2_GDB_VERSION_6_6 if BR2_bfin
>  	default BR2_GDB_VERSION_6_7_1_AVR32_2_1_5 if BR2_avr32
> -	default BR2_GDB_VERSION_7_5
> +	default BR2_GDB_VERSION_7_7

I'm not sure we want to jump straight to 7.7 for all architectures.
We're usually a bit conservative with regard to the version of toolchain
components. So I'd suggest instead to add 7.6 and 7.7. Make 7.6 the new
default for all architectures except PPC64, and make 7.6 unavailable
for PPC64, and therefore select 7.7 for PPC64. Of course, all older gdb
versions should be unavailable for PPC64.

Speaking of component versions, your PATCH 1/2 indicates that gcc 4.9
and glibc 2.19 are needed for PPC64. Can you make sure that the
relevant toolchain component versions dependencies are added, so that
users can't select a too old glibc version, or a too old gcc version?

Another question is: are there some existing, publicly available,
pre-built toolchain for PPC64 ?

My last question is: how far goes your interest for PPC64 ? When we
start supporting a new architecture in Buildroot, we generally add it
in the autobuilders, which means that a significant portion of the
Buildroot packages get built against this new architecture. This often
raises a number of build failures. Would you be willing to help fixing
those? To help doing this, we generally offer to people in charge of a
given architecture to receive a daily e-mail listing the build failures
that occurred on that architecture. A good thing is that this helps the
persons maintaining this infrastructure notice which userspace packages
need to be taken care of.

Thanks a lot again for your contribution, really nice!

Thomas

On 05/11/2014 02:54 PM, Thomas Petazzoni wrote:
> Dear Cody P Schafer,
>
> I had a fairly similar patch sitting in my patch stack.
>
> On Sun, 11 May 2014 14:11:13 -0700, Cody P Schafer wrote:
>
>> diff --git a/package/gdb/Config.in.host b/package/gdb/Config.in.host
>> index e853469..77c5459 100644
>> --- a/package/gdb/Config.in.host
>> +++ b/package/gdb/Config.in.host
>> @@ -19,7 +19,7 @@ choice
>>   	depends on !BR2_microblaze
>>   	default BR2_GDB_VERSION_6_6 if BR2_bfin
>>   	default BR2_GDB_VERSION_6_7_1_AVR32_2_1_5 if BR2_avr32
>> -	default BR2_GDB_VERSION_7_5
>> +	default BR2_GDB_VERSION_7_7
>
> I'm not sure we want to jump straight to 7.7 for all architectures.
> We're usually a bit conservative with regard to the version of toolchain
> components. So I'd suggest instead to add 7.6 and 7.7. Make 7.6 the new
> default for all architectures except PPC64, and make 7.6 unavailable
> for PPC64, and therefore select 7.7 for PPC64. Of course, all older gdb
> versions should be unavailable for PPC64.

So long as s/PPC64/PPC64le/, sure.

> Speaking of component versions, your PATCH 1/2 indicates that gcc 4.9
> and glibc 2.19 are needed for PPC64. Can you make sure that the
> relevant toolchain component versions dependencies are added, so that
> users can't select a too old glibc version, or a too old gcc version?

Will do.

> Another question is: are there some existing, publicly available,
> pre-built toolchain for PPC64 ?

https://www.kernel.org/pub/tools/crosstool/ has a ppc64 one (without a 
libc). I'm not aware of one shipping with a libc.
I don't know of any ppc64le prebuilt toolchains.

> My last question is: how far goes your interest for PPC64 ? When we
> start supporting a new architecture in Buildroot, we generally add it
> in the autobuilders, which means that a significant portion of the
> Buildroot packages get built against this new architecture. This often
> raises a number of build failures. Would you be willing to help fixing
> those? To help doing this, we generally offer to people in charge of a
> given architecture to receive a daily e-mail listing the build failures
> that occurred on that architecture. A good thing is that this helps the
> persons maintaining this infrastructure notice which userspace packages
> need to be taken care of.

I'm really only doing this because I end up using buildroot to build 
netboot images to test kernel changes I make on real hardware.
It's entirely a yak shaving project to me.

That said, I'm fine with getting emails, but can't promise anything 
about actually helping fix things.

Dear Cody P Schafer,

On Mon, 12 May 2014 12:08:05 -0700, Cody P Schafer wrote:

> > I'm not sure we want to jump straight to 7.7 for all architectures.
> > We're usually a bit conservative with regard to the version of toolchain
> > components. So I'd suggest instead to add 7.6 and 7.7. Make 7.6 the new
> > default for all architectures except PPC64, and make 7.6 unavailable
> > for PPC64, and therefore select 7.7 for PPC64. Of course, all older gdb
> > versions should be unavailable for PPC64.
> 
> So long as s/PPC64/PPC64le/, sure.

Right. I guess PPC64 (big endian) has been supported since a long time,
is this correct?

> > Another question is: are there some existing, publicly available,
> > pre-built toolchain for PPC64 ?
> 
> https://www.kernel.org/pub/tools/crosstool/ has a ppc64 one (without a 
> libc). I'm not aware of one shipping with a libc.

Toolchains without a libc are not very useful in the context of
Buildroot.

> I don't know of any ppc64le prebuilt toolchains.

Ok, no problem :)

> > My last question is: how far goes your interest for PPC64 ? When we
> > start supporting a new architecture in Buildroot, we generally add it
> > in the autobuilders, which means that a significant portion of the
> > Buildroot packages get built against this new architecture. This often
> > raises a number of build failures. Would you be willing to help fixing
> > those? To help doing this, we generally offer to people in charge of a
> > given architecture to receive a daily e-mail listing the build failures
> > that occurred on that architecture. A good thing is that this helps the
> > persons maintaining this infrastructure notice which userspace packages
> > need to be taken care of.
> 
> I'm really only doing this because I end up using buildroot to build 
> netboot images to test kernel changes I make on real hardware.
> It's entirely a yak shaving project to me.
> 
> That said, I'm fine with getting emails, but can't promise anything 
> about actually helping fix things.

No problem, that's fine: it's a best effort thing. It's just that when
we support an architecture in Buildroot, we would like to have a fairly
decent support. It really isn't nice if we pretend to support a given
architecture, and in fact things quickly fall apart when a new user
comes in and tries to build a given configuration of packages for this
architecture.

Thomas

On 05/12/2014 12:21 PM, Thomas Petazzoni wrote:
> Dear Cody P Schafer,
>
> On Mon, 12 May 2014 12:08:05 -0700, Cody P Schafer wrote:
>
>>> I'm not sure we want to jump straight to 7.7 for all architectures.
>>> We're usually a bit conservative with regard to the version of toolchain
>>> components. So I'd suggest instead to add 7.6 and 7.7. Make 7.6 the new
>>> default for all architectures except PPC64, and make 7.6 unavailable
>>> for PPC64, and therefore select 7.7 for PPC64. Of course, all older gdb
>>> versions should be unavailable for PPC64.
>>
>> So long as s/PPC64/PPC64le/, sure.
>
> Right. I guess PPC64 (big endian) has been supported since a long time,
> is this correct?

Yep, ppc64 (big endian) has been around and supported in gcc/glibc/gdb 
for quite a while now (looks like the first gdb support landed in 2007).