Makeopts DEBUG=-g kernel option

[Dirk Kotze]

Hi again

Just some feedback - it seems that I have isolated the problem below with the help of a 2005 post by John Nielsen to freebsd-questions (http://lists.freebsd.org/pipermail/freebsd-sparc64/2005-August/003423.html).

I have isolated the problem as being caused by the compiler optimization flags, specifically the "-O2 -pipe" flags (the default flags used when "makeoptions  DEBUG=-g" is not specified in the kernel configuration).  I have proved that the DEBUG flag per se has nothing to do with it by removing it, and then adding makeoptions COPTFLAGS="-O -pipe" to the kernel config.  This boots fine.

Funny though, the exact original kernel used (without DEBUG and compiled with -O2) works fine on other hardware (e.g. the Tyan Tank G20 B5211 motherboard with an Intel Core2Duo CPU).  It only fails on the WADE-8020 board. It must be some specific hardware driver used on the WADE-8020 motherboard that breaks when compiled with -O2.

If anyone has suggestions as to how I can trace the problem further (so that I can log a bug with the BSD community), this will be appreciated.  Hopefully I can ensure that a future user does not struggle with the same problem I did.

As always, thanks for the help.

Regards,
Dirk Kotze
Developer

> From: Dirk Kotze 
> Sent: Monday, January 23, 2012 4:27 PM
> To: 'freebsd-questions at freebsd.org'
> Subject: Makeopts DEBUG=-g kernel option
>
> Hi there
>
> I'm experiencing the following problem: All is well when I boot the standard FreeBSD 8.2 GENERIC kernel.  The moment 
> however when I comment out the line the line below, the kernel hangs upon boot after detecting the em0 device (the 
> motherboard has 2 Intel 8257x dual Gigabit Ethernet cards).
> makeopts   DEBUG=-g
>
> I'm using FreeBSD 8.2 on a WADE-8020 motherboard with an Intel QM57 chipset and Intel Core i5 CPU.  
>
> The reason I'm trying to remove debugging options from the kernel is that I am trying to make the kernel footprint 
> smaller.
>
> This leaves me with a few questions:
> 1) What are the risks/drawbacks/advantages of leaving debugging symbols in the kernel?
> 2) Why would debug symbols (of all things!) make the difference between a working and non-working kernel?
> 3) Does this point in the direction of some other (more serious problem perhaps?) with the hardware and/or other 
> kernel drivers?
>
> Thanks so much for any assistance.
>
> Regards,
> Dirk Kotze
> Developer
>
>
>         Tel: +27 12 672 7281
>      Fax: +27 12 665 1343
> Postal: P.O. Box 7991, Centurion, 0046
> Physical: 1 Pieter street, Highveld Park, Centurion
>

Important Notice:

This e-mail and its contents are subject to the Nanoteq (Pty) Ltd e-mail legal notice available at:
http://www.nanoteq.com/corp_profile/disclaimer.asp


Important Notice:

This e-mail and its contents are subject to the Nanoteq (Pty) Ltd e-mail legal notice available at:
http://www.nanoteq.com/corp_profile/disclaimer.asp
-------------- next part --------------
The message does not contain any threats
AVG for MS Exchange Server (10.0.1416 - 2109/4756)