This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2 09/10] Avoid undefined behavior in expression dumping
On 10/02/2018 05:44 AM, Tom Tromey wrote:
> -fsanitize=undefined pointed out undefined behavior in
> dump_raw_expression like:
>
> runtime error: load of value 2887952, which is not a valid value for type 'exp_opcode'
>
> dump_raw_expression will try to print the opcode for each element of
> the expression, even when it is not valid. To allow this, but have it
> avoid undefined behavior, this patch sets the underlying type of enum
> exp_opcode, and arranges for op_name to handle invalid opcodes more
> nicely.
>
> Before this patch, debug-expr.exp shows:
>
> Dump of expression @ 0x60f000007750, before conversion to prefix form:
> Language c, 8 elements, 16 bytes each.
> Index Opcode Hex Value String Value
> 0 OP_TYPE 89 Y...............
> <unknown 3851920> 107820862850704 ..:..b..........
> 2 OP_TYPE 89 Y...............
> 3 OP_VAR_VALUE 40 (...............
> 4 <unknown 2807568> 107820861806352 ..*..b..........
> 5 <unknown 2806368> 107820861805152 `.*..b..........
> 6 OP_VAR_VALUE 40 (...............
> 7 UNOP_MEMVAL_TYPE 57 9...............
>
> Afterward, the output is:
>
> Dump of expression @ 0x4820f90, before conversion to prefix form:
> Language c, 8 elements, 16 bytes each.
> Index Opcode Hex Value String Value
> 0 OP_TYPE 89 Y...............
> 1 unknown opcode: 176 75444400 .0..............
> 2 OP_TYPE 89 Y...............
> 3 OP_VAR_VALUE 40 (...............
> 4 OP_BOOL 74616912 P.r.............
> 5 unknown opcode: 128 74615680 ..r.............
> 6 OP_VAR_VALUE 40 (...............
> 7 UNOP_MEMVAL_TYPE 57 9...............
>
LGTM. Thanks for adding the example.
Thanks,
Pedro Alves