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]
Message-ID: <46955BB1.20200@windriver.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ