This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch]: Add endianess to valprint routines
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: deuling at de dot ibm dot com (Markus Deuling)
- Cc: gdb-patches at sourceware dot org (GDB Patches)
- Date: Tue, 20 May 2008 17:24:22 +0200 (CEST)
- Subject: Re: [patch]: Add endianess to valprint routines
Markus Deuling wrote:
> * valprint.c (print_hex_chars, print_octal_chars, print_decimal_chars,
> print_binary_chars, print_char_chars): Add endianess parameter and
> replace gdbarch_byte_order.
> (val_print_type_code_int): Introduce gdbarch_byte_order to get at the
> endianness. Update call to print_hex_chars.
> * valprint.h (print_hex_chars, print_octal_chars, print_decimal_chars,
> print_binary_chars, print_char_chars): Add endianess parameter.
> * printcmd.c (print_scalar_formatted): Introduce gdbarch_byte_order to
> get at the endianness. Update print_*_char calls to use endianness.
This is basically OK, except for:
> #define START_P \
> - ((gdbarch_byte_order (current_gdbarch) == BFD_ENDIAN_BIG) ? valaddr : valaddr + len - 1)
> + ((endianness == BFD_ENDIAN_BIG) ? valaddr : valaddr + len - 1)
> #define NOT_END_P \
> - ((gdbarch_byte_order (current_gdbarch) == BFD_ENDIAN_BIG) ? (p < valaddr + len) : (p >= valaddr))
> + ((endianness == BFD_ENDIAN_BIG) ? (p < valaddr + len) : (p >= valaddr))
> #define NEXT_P \
> - ((gdbarch_byte_order (current_gdbarch) == BFD_ENDIAN_BIG) ? p++ : p-- )
> + ((endianness == BFD_ENDIAN_BIG) ? p++ : p-- )
Can we please avoid having macros that implicitly access local variables?
As a minor nit, calling those variables "byte_order" instead of
"endianness" seems to be more common usage in GDB.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com