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

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

[Tom Tromey]

I tried a build on macOS today and it failed due to a mismatch between
the printf format and the type in aarch64-linux-tdep.c.  This patch
fixes the problem by using pulongest and %s rather than %ld.

gdb/ChangeLog
2018-10-02  Tom Tromey  <tom@tromey.com>

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

diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c
index e55b1a726f..f2962075c5 100644
--- a/gdb/aarch64-linux-tdep.c
+++ b/gdb/aarch64-linux-tdep.c
@@ -247,8 +247,8 @@ aarch64_linux_sigframe_init (const struct tramp_frame *self,
 	    vq = sve_vq_from_vl (extract_unsigned_integer (buf, 2, byte_order));
 
 	    if (vq != tdep->vq)
-	      error (_("Invalid vector length in signal frame %d vs %ld."), vq,
-		     tdep->vq);
+	      error (_("Invalid vector length in signal frame %d vs %s."), vq,
+		     pulongest (tdep->vq));
 
 	    if (size >= AARCH64_SVE_CONTEXT_SIZE (vq))
 	      sve_regs = section + AARCH64_SVE_CONTEXT_REGS_OFFSET;
-- 
2.17.1

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

[Tom Tromey]

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(-)

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

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

[Sergio Durigan Junior]

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
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

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

[Tom Tromey]

>>>>> "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