From: Claudio Jeker Subject: Re: debug symbols in regress tests To: Theo Buehler Cc: tech@openbsd.org Date: Sun, 24 Nov 2024 14:34:27 +0100 On Sun, Nov 24, 2024 at 02:19:34PM +0100, Theo Buehler wrote: > On Sun, Nov 24, 2024 at 02:09:24PM +0100, Claudio Jeker wrote: > > On Sun, Nov 24, 2024 at 01:58:55PM +0100, Theo Buehler wrote: > > > On Sun, Nov 24, 2024 at 01:47:10PM +0100, Claudio Jeker wrote: > > > > On Sun, Nov 24, 2024 at 10:09:49AM +0100, Theo Buehler wrote: > > > > > On Mon, Nov 04, 2024 at 11:32:47AM +0100, Theo Buehler wrote: > > > > > > When a regress test fails or crashes, it's useful to have debugging > > > > > > symbols available and it is a bit annoying to have to recompile. Is > > > > > > there a reason not to have them available by default - other than maybe > > > > > > disk space in obj/ on the machines that run full regress? > > > > > > > > > > I'd still like to have this. Any concern/objections? > > > > > > > > I also would like this. I just wonder if this should use DEBUG instead of > > > > CFLAGS but I'm always lost at all the ways to fiddle with the compiler > > > > tool chain. > > > > > > Thanks, makes sense. It's what bsd.lib.mk does as well and it works for > > > me. If this is preferred, I'm happy with that. > > > > If this is what's used in bsd.lib.mk then it may be better to use that. > > > > I dislike "DEBUG ?= -g" because it may drop -g if make is called with > > DEBUG set to something else. I hit this case in kernel builds from time > > to time which results in no ctf symbols and a lot of cursing. > > One could maybe use DEBUG += -g but as I said, I'm lost with all the knobs > > that our Makefiles provide. > > CFLAGS aren't really overridable on the command line, so I added +=. > > I believe DEBUG should honor user settings, so ?= makes more sense to me, > and it's what's used elsewhere. If you want to change that, please let's > discuss that separately, and let's not get sidetracked here. > > I really just want -g to be added to CFLAGS by default for regress. I > really don't care which way it is achieved. > I think you should commit your original diff. It is the better/bigger hammer to this problem. -- :wq Claudio