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.
On Fri, 2003-06-06 at 10:27, Timothy Miller wrote:
> 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.
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
Richard B. Johnson wrote:
>
> 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".
Bryan O'Sullivan wrote:
>
>
> 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.
>
Oh! So GCC is trying to be smart about printf format strings? Cool.
Never mind then. :)
On Fri, 6 Jun 2003, Timothy Miller wrote:
>
>
> Richard B. Johnson wrote:
>
> >
> > 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".
>
So why the hell did you forward this to linux-kernel when I answered
you privately?
Richard B. Johnson wrote:
>
>
> 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.