From: Markus Deuling <deuling@de.ibm.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [patch]: Add endianess to valprint routines
Date: Wed, 21 May 2008 16:45:00 -0000 [thread overview]
Message-ID: <4833CD89.4070900@de.ibm.com> (raw)
In-Reply-To: <200805201524.m4KFOMQE011363@d12av02.megacenter.de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]
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
[-- Attachment #2: diff-vprint-endian --]
[-- Type: text/plain, Size: 6448 bytes --]
diff -urpN src/gdb/printcmd.c dev/gdb/printcmd.c
--- src/gdb/printcmd.c 2008-05-21 06:30:21.000000000 +0200
+++ dev/gdb/printcmd.c 2008-05-21 08:35:55.000000000 +0200
@@ -322,6 +322,7 @@ print_scalar_formatted (const void *vala
{
LONGEST val_long = 0;
unsigned int len = TYPE_LENGTH (type);
+ enum bfd_endian byte_order = gdbarch_byte_order (current_gdbarch);
/* If we get here with a string format, try again without it. Go
all the way back to the language printers, which may call us
@@ -340,20 +341,20 @@ print_scalar_formatted (const void *vala
switch (format)
{
case 'o':
- print_octal_chars (stream, valaddr, len);
+ print_octal_chars (stream, valaddr, len, byte_order);
return;
case 'u':
case 'd':
- print_decimal_chars (stream, valaddr, len);
+ print_decimal_chars (stream, valaddr, len, byte_order);
return;
case 't':
- print_binary_chars (stream, valaddr, len);
+ print_binary_chars (stream, valaddr, len, byte_order);
return;
case 'x':
- print_hex_chars (stream, valaddr, len);
+ print_hex_chars (stream, valaddr, len, byte_order);
return;
case 'c':
- print_char_chars (stream, valaddr, len);
+ print_char_chars (stream, valaddr, len, byte_order);
return;
default:
break;
diff -urpN src/gdb/valprint.c dev/gdb/valprint.c
--- src/gdb/valprint.c 2008-05-09 11:34:57.000000000 +0200
+++ dev/gdb/valprint.c 2008-05-21 08:47:30.000000000 +0200
@@ -313,6 +313,8 @@ void
val_print_type_code_int (struct type *type, const gdb_byte *valaddr,
struct ui_file *stream)
{
+ enum bfd_endian byte_order = gdbarch_byte_order (current_gdbarch);
+
if (TYPE_LENGTH (type) > sizeof (LONGEST))
{
LONGEST val;
@@ -330,7 +332,7 @@ val_print_type_code_int (struct type *ty
complement (a reasonable assumption, I think) and do
better than this. */
print_hex_chars (stream, (unsigned char *) valaddr,
- TYPE_LENGTH (type));
+ TYPE_LENGTH (type), byte_order);
}
}
else
@@ -525,7 +527,7 @@ print_decimal_floating (const gdb_byte *
void
print_binary_chars (struct ui_file *stream, const gdb_byte *valaddr,
- unsigned len)
+ unsigned len, enum bfd_endian byte_order)
{
#define BITS_IN_BYTES 8
@@ -541,7 +543,7 @@ print_binary_chars (struct ui_file *stre
/* FIXME: We should be not printing leading zeroes in most cases. */
- if (gdbarch_byte_order (current_gdbarch) == BFD_ENDIAN_BIG)
+ if (byte_order == BFD_ENDIAN_BIG)
{
for (p = valaddr;
p < valaddr + len;
@@ -585,7 +587,7 @@ print_binary_chars (struct ui_file *stre
*/
void
print_octal_chars (struct ui_file *stream, const gdb_byte *valaddr,
- unsigned len)
+ unsigned len, enum bfd_endian byte_order)
{
const gdb_byte *p;
unsigned char octa1, octa2, octa3, carry;
@@ -628,7 +630,7 @@ print_octal_chars (struct ui_file *strea
carry = 0;
fputs_filtered ("0", stream);
- if (gdbarch_byte_order (current_gdbarch) == BFD_ENDIAN_BIG)
+ if (byte_order == BFD_ENDIAN_BIG)
{
for (p = valaddr;
p < valaddr + len;
@@ -733,19 +735,12 @@ print_octal_chars (struct ui_file *strea
*/
void
print_decimal_chars (struct ui_file *stream, const gdb_byte *valaddr,
- unsigned len)
+ unsigned len, enum bfd_endian byte_order)
{
#define TEN 10
-#define TWO_TO_FOURTH 16
#define CARRY_OUT( x ) ((x) / TEN) /* extend char to int */
#define CARRY_LEFT( x ) ((x) % TEN)
#define SHIFT( x ) ((x) << 4)
-#define START_P \
- ((gdbarch_byte_order (current_gdbarch) == BFD_ENDIAN_BIG) ? valaddr : valaddr + len - 1)
-#define NOT_END_P \
- ((gdbarch_byte_order (current_gdbarch) == BFD_ENDIAN_BIG) ? (p < valaddr + len) : (p >= valaddr))
-#define NEXT_P \
- ((gdbarch_byte_order (current_gdbarch) == BFD_ENDIAN_BIG) ? p++ : p-- )
#define LOW_NIBBLE( x ) ( (x) & 0x00F)
#define HIGH_NIBBLE( x ) (((x) & 0x0F0) >> 4)
@@ -782,9 +777,9 @@ print_decimal_chars (struct ui_file *str
* LSD end.
*/
decimal_digits = 0; /* Number of decimal digits so far */
- p = START_P;
+ p = (byte_order == BFD_ENDIAN_BIG) ? valaddr : valaddr + len - 1;
flip = 0;
- while (NOT_END_P)
+ while ((byte_order == BFD_ENDIAN_BIG) ? (p < valaddr + len) : (p >= valaddr))
{
/*
* Multiply current base-ten number by 16 in place.
@@ -814,7 +809,10 @@ print_decimal_chars (struct ui_file *str
/* Take low nibble and bump our pointer "p".
*/
digits[0] += LOW_NIBBLE (*p);
- NEXT_P;
+ if (byte_order == BFD_ENDIAN_BIG)
+ p++;
+ else
+ p--;
flip = 0;
}
@@ -868,14 +866,14 @@ print_decimal_chars (struct ui_file *str
void
print_hex_chars (struct ui_file *stream, const gdb_byte *valaddr,
- unsigned len)
+ unsigned len, enum bfd_endian byte_order)
{
const gdb_byte *p;
/* FIXME: We should be not printing leading zeroes in most cases. */
fputs_filtered ("0x", stream);
- if (gdbarch_byte_order (current_gdbarch) == BFD_ENDIAN_BIG)
+ if (byte_order == BFD_ENDIAN_BIG)
{
for (p = valaddr;
p < valaddr + len;
@@ -900,11 +898,11 @@ print_hex_chars (struct ui_file *stream,
void
print_char_chars (struct ui_file *stream, const gdb_byte *valaddr,
- unsigned len)
+ unsigned len, enum bfd_endian byte_order)
{
const gdb_byte *p;
- if (gdbarch_byte_order (current_gdbarch) == BFD_ENDIAN_BIG)
+ if (byte_order == BFD_ENDIAN_BIG)
{
p = valaddr;
while (p < valaddr + len - 1 && *p == 0)
diff -urpN src/gdb/valprint.h dev/gdb/valprint.h
--- src/gdb/valprint.h 2008-01-01 23:53:13.000000000 +0100
+++ dev/gdb/valprint.h 2008-05-21 08:33:32.000000000 +0200
@@ -69,17 +69,17 @@ extern void val_print_type_code_flags (s
struct ui_file *stream);
extern void print_binary_chars (struct ui_file *, const gdb_byte *,
- unsigned int);
+ unsigned int, enum bfd_endian);
extern void print_octal_chars (struct ui_file *, const gdb_byte *,
- unsigned int);
+ unsigned int, enum bfd_endian);
extern void print_decimal_chars (struct ui_file *, const gdb_byte *,
- unsigned int);
+ unsigned int, enum bfd_endian);
extern void print_hex_chars (struct ui_file *, const gdb_byte *,
- unsigned int);
+ unsigned int, enum bfd_endian);
extern void print_char_chars (struct ui_file *, const gdb_byte *,
- unsigned int);
+ unsigned int, enum bfd_endian);
#endif
next prev parent reply other threads:[~2008-05-21 7:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-19 15:19 Markus Deuling
2008-05-20 17:48 ` Ulrich Weigand
2008-05-21 16:45 ` Markus Deuling [this message]
2008-05-21 18:35 ` Ulrich Weigand
2008-05-23 16:32 ` Markus Deuling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4833CD89.4070900@de.ibm.com \
--to=deuling@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox