linux-kernel - Re: [PATCH] Pass -g to assembler under CONFIG_DEBUG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Jul 2007 17:37:37 -0500
From:	Jason Wessel <jason.wessel@...driver.com>
To:	Roland McGrath <roland@...hat.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Pass -g to assembler under CONFIG_DEBUG_INFO

Roland McGrath wrote:
>> Jason's kgdb tree does
>>
>> AFLAGS		+= -gdwarf2
>>
>> (for all architectures!)  Which is better?
>>     
>
> It makes no difference on any platform I care about.  -g says "turn on the
> default flavor for the target", while -gdwarf2 turns on DWARF flavor even
> if the default is different.  Every target I know anything in particular
> about has DWARF as the default flavor anyway.
>   

The -gdwarf2 had a specific reason. 

I had not looked at the recent gcc 4.1.x + binutils, but in the gcc 
3.x.x compilers when you pass just -g the assembler emitted stabs debug 
data on most archs.  This not only made the debug object files bigger, 
but also the stabs sections were not always parsed correctly in various 
versions of gdb.  I found the dwarf2 sections to be smaller and more 
reliable to allow source level assembly stepping as well as debug frame 
info through the assembly linked functions (ie better back traces).

If it is the case that the gcc 4.1.x + binutils all emit dwarf2 as the 
default you can use just -g.

I'll also take a moment to mention that in the kgdb branch, I also 
modified the top level make file so that you can un-optimize kernel 
modules compiled outside the kernel tree.  I find this this is useful if 
you want to step through significant chunks of code in your kernel 
module IE:

make ARCH=i386 -C KERN_SRC_LOCATION M=/my_mod COMPTIMIZE=-O0

Jason.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/