This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]