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.