[FYI] Use pulongest in aarch64-linux-tdep.c

  While testing a patch on the buildbot, I got this error:

../../binutils-gdb/gdb/aarch64-linux-tdep.c: In function uint64_t aarch64_linux_core_read_vq(gdbarch*, bfd*):
../../binutils-gdb/gdb/aarch64-linux-tdep.c:285:29: error: format %ld expects argument of type long int, but argument 2 has type uint64_t {aka long long unsigned int} [-Werror=format=]

This patch avoids the problem by using pulongest rather than %ld.
This seems safe to me because, if aarch64-linux-tdep.c is included in
the build, then ULONGEST must be a 64-bit type.

gdb/ChangeLog
2018-08-15  Tom Tromey  <tom@tromey.com>

	* aarch64-linux-tdep.c (aarch64_linux_core_read_vq): Use pulongest.
---
 gdb/ChangeLog            | 4 ++++
 gdb/aarch64-linux-tdep.c | 5 +++--
 2 files changed, 7 insertions(+), 2 deletions(-)
  

On Wednesday, August 15 2018, Tom Tromey wrote:

> While testing a patch on the buildbot, I got this error:
>
> ../../binutils-gdb/gdb/aarch64-linux-tdep.c: In function uint64_t aarch64_linux_core_read_vq(gdbarch*, bfd*):
> ../../binutils-gdb/gdb/aarch64-linux-tdep.c:285:29: error: format %ld expects argument of type long int, but argument 2 has type uint64_t {aka long long unsigned int} [-Werror=format=]
>
> This patch avoids the problem by using pulongest rather than %ld.
> This seems safe to me because, if aarch64-linux-tdep.c is included in
> the build, then ULONGEST must be a 64-bit type.

Hi Tom,

It seems like this commit should have been applied to the 8.2 branch,
but wasn't.  GDB 8.2 was released without it, and it breaks to build on
i686 and armvhl, as can be seen here:

  https://koji.fedoraproject.org/koji/taskinfo?taskID=29499845

I'll backport the commit locally and rebuild it, but I thought it'd be
good to mention publicly in case anyone else is seeing these failures.

Cheers,

> gdb/ChangeLog
> 2018-08-15  Tom Tromey  <tom@tromey.com>
>
> 	* aarch64-linux-tdep.c (aarch64_linux_core_read_vq): Use pulongest.
> ---
>  gdb/ChangeLog            | 4 ++++
>  gdb/aarch64-linux-tdep.c | 5 +++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/gdb/ChangeLog b/gdb/ChangeLog
> index d16920d80e9..9fac8ccf5f4 100644
> --- a/gdb/ChangeLog
> +++ b/gdb/ChangeLog
> @@ -1,3 +1,7 @@
> +2018-08-15  Tom Tromey  <tom@tromey.com>
> +
> +	* aarch64-linux-tdep.c (aarch64_linux_core_read_vq): Use pulongest.
> +
>  2018-08-14  Jan Vrany  <jan.vrany@fit.cvut.cz>
>  
>  	* mi/mi-cmd-disas.c (mi_cmd_disassemble): Add -a option.
> diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c
> index 99e6a1590b8..389f4f494ec 100644
> --- a/gdb/aarch64-linux-tdep.c
> +++ b/gdb/aarch64-linux-tdep.c
> @@ -282,12 +282,13 @@ aarch64_linux_core_read_vq (struct gdbarch *gdbarch, bfd *abfd)
>    if (vq > AARCH64_MAX_SVE_VQ)
>      {
>        warning (_("SVE Vector length in core file not supported by this version"
> -		 " of GDB.  (VQ=%ld)"), vq);
> +		 " of GDB.  (VQ=%s)"), pulongest (vq));
>        return 0;
>      }
>    else if (vq == 0)
>      {
> -      warning (_("SVE Vector length in core file is invalid. (VQ=%ld"), vq);
> +      warning (_("SVE Vector length in core file is invalid. (VQ=%s"),
> +	       pulongest (vq));
>        return 0;
>      }
>  
> -- 
> 2.17.1
  

>>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes:

Sergio> It seems like this commit should have been applied to the 8.2 branch,
Sergio> but wasn't.  GDB 8.2 was released without it, and it breaks to build on
Sergio> i686 and armvhl, as can be seen here:

I didn't even think of that for this patch :)

I think it's fine for the branch but maybe not terrible that it isn't
there already, because normally release builds don't use the warnings.

Tom