How can I disable compile optimization in kernel for friendly debugging, Thanks
On Thu, 19 Apr 2018 16:58:40 +0800, sizel said:
How can I disable compile optimization in kernel for friendly debugging, Thanks
First off, there are parts of the kernel that *WILL* explode if you try to build with -O0 - in particular, any code that expects static inlines to be treated as part of the unit they are inlined into for the purposes of __builtin_return_address() and similar. Second, modern gdb is perfectly able to deal with -O2 optimization, especially if you build with -g. (In the kernel build, CONFIG_DEBUG_INFO=y will do the right thing for this). What specific problems were you hitting in debugging that made you want to disable optimization?
On 2018-04-19 13:28, valdis.kletnieks@vt.edu wrote:
On Thu, 19 Apr 2018 16:58:40 +0800, sizel said:
How can I disable compile optimization in kernel for friendly debugging, Thanks
First off, there are parts of the kernel that *WILL* explode if you try to build with -O0 - in particular, any code that expects static inlines to be treated as part of the unit they are inlined into for the purposes of __builtin_return_address() and similar.
Can you elaborate more on that?
Second, modern gdb is perfectly able to deal with -O2 optimization, especially if you build with -g. (In the kernel build, CONFIG_DEBUG_INFO=y will do the right thing for this).
I don't think so. According to my experience, GDB is not good enough to deal with -O2 optimization. Maybe my gdb is not modern enough? I am using gdb7.11 (Ubuntu 7.11.1-0ubuntu1~16.5) Yubin
On Fri, Apr 20, 2018 at 11:39:10PM +0800, Yubin Ruan wrote:
On 2018-04-19 13:28, valdis.kletnieks@vt.edu wrote:
On Thu, 19 Apr 2018 16:58:40 +0800, sizel said:
How can I disable compile optimization in kernel for friendly debugging, Thanks
First off, there are parts of the kernel that *WILL* explode if you try to build with -O0 - in particular, any code that expects static inlines to be treated as part of the unit they are inlined into for the purposes of __builtin_return_address() and similar.
Can you elaborate more on that?
Second, modern gdb is perfectly able to deal with -O2 optimization, especially if you build with -g. (In the kernel build, CONFIG_DEBUG_INFO=y will do the right thing for this).
I don't think so. According to my experience, GDB is not good enough to deal with -O2 optimization.
Maybe my gdb is not modern enough? I am using gdb7.11 (Ubuntu 7.11.1-0ubuntu1~16.5)
That is an old version of gdb, why not try a more modern one? Also, why do you even need to use a debugger on a kernel image? It's very rare that this is needed, with all of the built-in debugging tools that the kernel already has. What have you tried that did not work out? Usually gdb is only needed if you are bringing up new hardware. good luck! greg k-h
On 2018-04-20 17:44, Greg KH wrote: [...]
Second, modern gdb is perfectly able to deal with -O2 optimization, especially if you build with -g. (In the kernel build, CONFIG_DEBUG_INFO=y will do the right thing for this).
I don't think so. According to my experience, GDB is not good enough to deal with -O2 optimization.
Maybe my gdb is not modern enough? I am using gdb7.11 (Ubuntu 7.11.1-0ubuntu1~16.5)
That is an old version of gdb, why not try a more modern one?
Whoop, don't know that...
Also, why do you even need to use a debugger on a kernel image?
no, usually printk is enough. Yubin
On Fri, 20 Apr 2018 23:39:10 +0800, Yubin Ruan said:
On 2018-04-19 13:28, valdis.kletnieks@vt.edu wrote:
On Thu, 19 Apr 2018 16:58:40 +0800, sizel said:
How can I disable compile optimization in kernel for friendly debugging, Thanks
First off, there are parts of the kernel that *WILL* explode if you try to build with -O0 - in particular, any code that expects static inlines to be treated as part of the unit they are inlined into for the purposes of __builtin_return_address() and similar.
Can you elaborate more on that?
grep for __builtin_return_address. Look where it's used. What does it return if it's inlined? What does it return if it's called as not inlined? For a simple example, consider this code from lib/smp_processor_id.c: in function check_preemption_disabled(): printk(KERN_ERR "BUG: using %s%s() in preemptible [%08x] code: %s/%d\n", what1, what2, preempt_count() - 1, current->comm, current->pid); printk("caller is %pS\n", __builtin_return_address(0)); dump_stack(); If __builtin_return_address is not inlined, that call points at the printk() call. If it *is* inlined, it points at the return point in the function that called check_preemption_disabled(). There's a whole bunch of much more subtle inlining bugs.
Second, modern gdb is perfectly able to deal with -O2 optimization, especially if you build with -g. (In the kernel build, CONFIG_DEBUG_INFO=y will do the right thing for this). >
I don't think so. According to my experience, GDB is not good enough to deal with -O2 optimization.
Give an actual example. In particular, an example where '-O2 -g' doesn't work. That's important - if a variable has been lifted out of a loop, or even optimized out of existence, gdb needs the debug info from -g to figure out what's going on. In fact, -g is so important for gdb use that even -O0 without -g often gives gdb indigestion.
Maybe my gdb is not modern enough? I am using gdb7.11 (Ubuntu 7.11.1-0ubuntu1~16.5)
That's over 2 years old.
On 2018-04-20 16:08, valdis.kletnieks@vt.edu wrote:
On Fri, 20 Apr 2018 23:39:10 +0800, Yubin Ruan said:
On 2018-04-19 13:28, valdis.kletnieks@vt.edu wrote:
On Thu, 19 Apr 2018 16:58:40 +0800, sizel said:
How can I disable compile optimization in kernel for friendly debugging, Thanks
First off, there are parts of the kernel that *WILL* explode if you try to build with -O0 - in particular, any code that expects static inlines to be treated as part of the unit they are inlined into for the purposes of __builtin_return_address() and similar.
Can you elaborate more on that?
grep for __builtin_return_address. Look where it's used. What does it return if it's inlined? What does it return if it's called as not inlined?
For a simple example, consider this code from lib/smp_processor_id.c: in function check_preemption_disabled():
printk(KERN_ERR "BUG: using %s%s() in preemptible [%08x] code: %s/%d\n", what1, what2, preempt_count() - 1, current->comm, current->pid);
printk("caller is %pS\n", __builtin_return_address(0)); dump_stack();
If __builtin_return_address is not inlined, that call points at the printk() call. If it *is* inlined, it points at the return point in the function that called check_preemption_disabled().
Thanks! I tested it and found that __builtin_return_addres's behavior is indeed as you described.
From this, I have a related question, can I treat __builtin_return_address() as a "builtin" stack unwinder (but only check for return addresses, or, where a function is called).
Yubin
On Sat, 21 Apr 2018 21:15:10 +0800, Yubin Ruan said:
From this, I have a related question, can I treat __builtin_return_address() as a "builtin" stack unwinder (but only check for return addresses, or, where a function is called).
It would seem possible, but it doesn't actually work that way. There's a reason why the kernel includes its own stack unwinder.
participants (4)
-
Greg KH -
sizel -
valdis.kletnieks＠vt.edu -
Yubin Ruan