On Wed, Oct 18, 2006 at 06:08:22PM +0200, Bruno Haible wrote: > Daniel Jacobowitz wrote: > > For GDB, we're looking at fixing our printf built in command once and > > for all. What we really need to do that is two separate interfaces > > that can talk to each other: one for parsing a format string, and one > > for converting arguments. > > Do you need a standard printf, or an extensible printf?
A standard printf. We're not trying to print out new things, we're trying to print out standard things using different sorts of arguments. Here's an example. You can open up GDB and say this: (gdb) printf "%lld\n", 1 1 But that "1" isn't ever something you can fetch with va_arg (long long). It's a GDB "struct value". Also, it may not be the same size as a host long long. A better example for that is just "long"; if you're running a 64-bit amd64 GDB, talking to a 32-bit ARM target, the target "long" type doesn't match the host's "long" type. GDB knows how to do all the necessary conversions. > How does what you need compare with the register_printf_function / > parse_printf_format facility in glibc's public header file <printf.h> ? Wow, I knew about register_printf_function, but I'd never noticed parse_printf_format before. printf breaks down into three stages: parsing the format string, recovering the arguments, and constructing the output string. We need completely normal versions of the first and third, but a non-va_arg based version of the second. If there was some way to construct a va_arg programmatically, which there isn't, we could do this with parse_printf_format (or the gnulib version) plus the existing vasnprintf. -- Daniel Jacobowitz CodeSourcery
