This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Does monitor.c work?
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: gdb at sources dot redhat dot com
- Date: Sun, 10 Aug 2003 15:39:26 -0400
- Subject: Does monitor.c work?
Hello,
monitor.c is based around a table of format strings vis:
m32r_cmds.set_break = "%x +bp\r"; /* set a breakpoint */
m32r_cmds.clr_break = "%x -bp\r"; /* clear a breakpoint */
(this is definitly far from unique to the m32r). Those format strings
are then passed to a printf like routine vis:
monitor_printf (char *pattern,...)
...
monitor_insert_breakpoint (CORE_ADDR addr, char *shadow)
...
monitor_printf (current_monitor->set_break, addr);
The problem, in monitor_vsprintf (which monitor_printf calls) is that
the CORE_ADDR is extracted as a long vis:
default:
arg_int = va_arg (args, long);
sprintf (sndbuf, format, arg_int);
break;
I'm guessing that on the little-endian i386 va_arg(long) and
va_arg(longlong) just happen to pick up the same leading bytes leaving
people with the impression that things ``work''. Arrrgh!!!!!!
Looking at the file, GraceS has started the correct trend by adding a
method (replaced a constant array).
const char *(*regname) (int index);
I think all format strings (the ones that take parameters) should be
converted into explicit methods.
Andrew
PS: Arrrg!!!
PPS: This means that I'm not going to try to fix monitor.c's
-Wformat-nonliteral warnings.