mirrors/binutils-gdb
1
0
Fork 0
mirror of https://sourceware.org/git/binutils-gdb.git synced 2024-11-25 02:53:48 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

x86: work around compiler diagnosing dangling pointer

Browse Source 
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.
This commit is contained in:
Jan Beulich 2023-04-24 10:37:12 +02:00
parent d4a174a5cb
commit 983db9932a
1 changed files with 6 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
opcodes/i386-dis.c
View File

@ -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;