Building with WITH_DEBUG (-g) in make.conf

Konstantin Belousov kostikbel at gmail.com
Wed Sep 5 02:31:50 UTC 2012


On Tue, Sep 04, 2012 at 11:50:35PM +0200, Dimitry Andric wrote:
> On 2012-09-04 17:53, Eitan Adler wrote:
> >On 4 September 2012 05:26, Jake Smith <jake at avenue22.net> wrote:
> ...
> >>It got me thinking, is there any reason why it would be a bad idea to 
> >>build
> >>all my ports with debug symbols from now on?
> >
> >>Are there any performance hits
> >
> >Yes. Code size grows and the flags may enable internal
> >debugging in the program itself.
> 
> There's a difference between just using '-g', which should never change
> the behaviour of the program at runtime, and adding -DDEBUG or similar
> flags on the command line, which may or may not enable extra code, or
> even cause totally different code paths.
> 
> What is not different, is that both -g and other debugging options will
> generally cause compiling and linking to take longer, since these stages
> will have to process the additional debug information.
> 
> 
> >>or security risks with this?
> >
> >no.
> 
> You cannot know in general.  If debug options enable a different code
> path, you might as well get a security problem with it for free. :)
> 
> I have seen many debug printf's which could easily be exploited for
> buffer overruns, etc.
> 
> However, only using '-g' should make no difference, indeed.
To nitpick, this is not true if you have code that explicitely
tries to use dwarf information from the resulting binary.
Think e.g. libunwind which can be configured to use .debug
sections.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20120905/9a85109d/attachment.pgp


More information about the freebsd-hackers mailing list