[binutils-gdb] x86: work around compiler diagnosing dangling pointer

[binutils-gdb] x86: work around compiler diagnosing dangling pointer

[Jan Beulich]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=983db9932a302f9e2ae1f1d4fd7c3149560bc269

commit 983db9932a302f9e2ae1f1d4fd7c3149560bc269
Author: Jan Beulich <jbeulich@suse.com>
Date:   Mon Apr 24 10:37:12 2023 +0200

    x86: work around compiler diagnosing dangling pointer
    
    For quite come time print_insn() has been storing the address of a local
    variable into info->private_data. Since the compiler can't know that the
    field won't be accessed again after print_insn() returns, it may kind of
    legitimately diagnose this. And recent enough gcc does as of the
    introduction of the fetch_error() return paths (replacing setjmp()-based
    error handling).
    
    Utilizing that neither prefix_name() nor i386_dis_printf() actually use
    info->private_data, zap the pointer in fetch_error(), after having
    retrieved it for local use.

Diff:
---
 opcodes/i386-dis.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index f021bdaa3e7..fc0515cd2b0 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -345,6 +345,12 @@ fetch_error (const instr_info *ins)
   const struct dis_private *priv = ins->info->private_data;
   const char *name = NULL;
 
+  /* Our caller has put a pointer to a local variable in info->private_data
+     and it is going to return right after this function has returned.  Some
+     compilers diagnose this as a dangling pointer.  Zap the pointer here to
+     avoid needing to do so on all involved return paths in the caller.  */
+  ins->info->private_data = NULL;
+
   if (ins->codep <= priv->the_buffer)
     return -1;