* Does monitor.c work?
@ 2003-08-10 19:39 Andrew Cagney
0 siblings, 0 replies; only message in thread
From: Andrew Cagney @ 2003-08-10 19:39 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2003-08-10 19:39 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-10 19:39 Does monitor.c work? Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).