Kernel printk format string compression: C syntax problem
Some of you may recall that I've been working on a way to compress kernel printk format strings so as to shrink the kernel memory image a bit. My results so far are that given the amount of space required for all kernel strings, I can compress them to half their original size. Given something the size of an allyesconfig kernel, that's not much compression over-all, but it's still interesting. Additionally, the means to compress the kernel messages are a compile-time issue and completely transparent to the coder.
I am, however, encountering a problem, and I was hoping some people who know C syntax better than both myself and the C syntax spec I found at "http://eic.sourceforge.net/iso_c.html" could help me solve it.
Here's an example of the problem:
This line from process.c starts out as:
printk("EIP: %04x:[<%08lx>] CPU: %d\n",0xffff & regs->xcs,regs->eip, (current_thread_info()->cpu));
And is replaced by:
printk( "EIP\200\3164x:[<\3168lx>] CPU\200%d\n" ,0xffff & regs->xcs,regs->eip, (current_thread_info()->cpu));
GCC 3.0.4 makes the following complaint:
arch/i386/kernel/process.c:173: warning: too many arguments for format
What I believe is happening is that where I have the escape code "\316" concatenated with the literal "8", the compiler is seeing it as "\3168" and doesn't want to take it. Now, it's just a warning, and it MAY be doing the right thing, but what I want to know is the PROPER UNAMBIGUOUS way to specify at 3-digit octal escape code which is followed immediately by a literal digit.
Any suggestions?
Thank you.
Quoted 10 lines · Timothy Miller
printk( "EIP\200\3164x:[<\3168lx>] CPU\200%d\n" ,0xffff & regs->xcs,regs->eip, (current_thread_info()->cpu));
GCC 3.0.4 makes the following complaint:
arch/i386/kernel/process.c:173: warning: too many arguments for formatWhat I believe is happening is that where I have the escape code "\316" concatenated with the literal "8", the compiler is seeing it as "\3168" and doesn't want to take it.
No. Look at the __attribute__ on printk in include/linux/kernel.h. GCC believes that printk takes a printf-style format string as its first argument, but you've mangled the string so that the number of format specifiers doesn't match the number of arguments.
<b
Quoted 7 lines · Bryan O'Sullivan
No. Look at the
__attribute__on printk ininclude/linux/kernel.h. GCC believes that printk takes a printf-style format string as its first argument, but you've mangled the string so that the number of format specifiers doesn't match the number of arguments.
Oh! So GCC is trying to be smart about printf format strings? Cool. Never mind then. :)
A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.53.0306061330520.7633@chaos
Quoted 7 lines · Richard B. Johnson
Aren't octal values supposed to always start with '0'? I remember this from some formal training when 'C' replaced Pascal. The second "
printf()" should__not__TAB over the text. With GNU gcc, it does. This doesn't mean that it's "correct", only that GNU does it that way.
Octal values start with '0' when they're numerical values. When they're in strings as escape characters, the C syntax is "\nnn". Every reference I find says that. Some script languages, however require that octal values start with '0' in strings, so csh would expect to see "\0nnn".
Additionally, when I compile in the dictionary into the program that does the string replacement, I get no complaints, although every character in there is "\nnn".
Quoted 12 lines · Timothy Miller
Quoted 7 lines · Richard B. Johnson
Aren't octal values supposed to always start with '0'? I remember this from some formal training when 'C' replaced Pascal. The second "
printf()" should__not__TAB over the text. With GNU gcc, it does. This doesn't mean that it's "correct", only that GNU does it that way.
Quoted 9 lines
Octal values start with '0' when they're numerical values. When they're in strings as escape characters, the C syntax is "\nnn". Every reference I find says that. Some script languages, however require that octal values start with '0' in strings, so csh would expect to see "\0nnn".
Additionally, when I compile in the dictionary into the program that does the string replacement, I get no complaints, although every character in there is "\nnn".
So why the hell did you forward this to linux-kernel when I answered you privately?
Quoted 6 lines · Richard B. Johnson
So why the hell did you forward this to linux-kernel when I answered you privately?
OH! My sincere apologies. I have the tendency to hit "Reply" instead of "Reply All", and so often when replying to a list posting, I have to manually enter the lkml address. When I didn't see lkml in the recipient list, I just assumed that I had hit the wrong button again.
I would never have done this intentionally.