Hi Uli,

Ulrich Weigand schrieb:
> 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.

I reworked the patch and replaced the macros as each of them was only unsed one time, anyway.
Re-tested on x86_64 without regression.

new ChangeLog:


	* valprint.c (print_hex_chars, print_octal_chars, print_decimal_chars,
	print_binary_chars, print_char_chars): Add byte_order parameter and
	replace gdbarch_byte_order.
	(print_decimal_chars): Replace START_P, NOT_END_P and NEXT_P by their
	expressions and remove them. Remove unused TWO_TO_FOURTH.
	(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 byte_order parameter.
	* printcmd.c (print_scalar_formatted): Introduce gdbarch_byte_order to
	get at the endianness. Update print_*_char calls to use byte_order.


Is this ok ?

Regards,
Markus

-- 
  Markus Deuling
  GNU Toolchain for Linux on Cell BE
  deuling@de.ibm.com