Well... I say "source level debugging doesn't work".

Do you have a better suggestion for fixing it?

Well, it works (for me, at least) even with optimization.  Do you remember why it wasn't for you?
My fear is that we're changing the code in the guise of making it more debuggable.  I'm ok with that if we have to do it, but I'd rather know why we have to do it, if I can.  Are you using studio and stabs maybe, or something?
I also, fwiw, have long-term dreams of actually shipping the DWARF we're producing here.  If we have to do this, that rather hurts that :)

It will take me some time to get you examples, but I can do that.

I have to agree with Rich... Disabling optimizations turns the binary into a totally different thing.  SOURCEDEBUG=yes should simply enable DWARF output.  I am all for making the separate variable (a SOURCEDEBUG sibling, if you will) that controls the amount of optimization.  This way, everyone is happy.

The feature #3844 was supposed to implement was:  "make source-level debugging easier",

not "make it possible to enable DWARF output".   I'm very much aware of what impact it has

to disable optimization, and I'd call it "out of scope" to consider ever shipping the

binaries produced for source level debugging.  I don't think #3844 is about that at all.

Heck, we don't even recommend using a debug build in production...  (also out of scope).
The problem is, debugging optimized objects simply doesn't work (much of the time).

If you think debugging optimized code works, I suspect you haven't used it much.
If I can't both turn on "-g" and turn off "-O" with some environment override, then

I have to edit Makefile.master to meet my needs, and we might as well have not even

bothered attempting #3844 (which was supposed to avoid that).
Maybe you guys want separate override mechanisms for "-g" vs "-O"?

I don't see any usefullness in that, but if you do, I'd go along.

Mostly, I just want to know what isn't working so I can see if there's a better way to fix it.

This is with studio tools, COPTFLAG= -O -g
$ cd $SRC/cmd/smbsrv/fksmbd

$ dbx 

Do one of: attach ${PID}

or: debug ${ROOT}/usr/lib/smbsrv/fksmbd

(dbx) attach 29923

Reading fksmbd

Reading ld.so.1

Reading libumem.so.1

Reading libfksmbsrv.so.1

Reading libfakekernel.so.1

[...]

Attached to process 29923 with 53 LWPs

t@1 (l@1) stopped in __sigtimedwait at 0xfe966555

0xfe966555: __sigtimedwait+0x0015:  jb       __cerror   [ 0xfe8cbed0, .-0x9a685 ]

Current function is main (optimized)

  188           sigval = sigwait(&set);

(dbx) stop in smb2_qinfo_file

(2) stop in smb2_qinfo_file

(dbx) cont                

Reading libidmap.so.1

[...]

t@40 (l@40) stopped in smb2_qinfo_file (optimized) at line 51 in file "smb2_qinfo_file.c"

   51   {

(dbx) next

t@40 (l@40) stopped in smb2_qinfo_file (optimized) at line 52 in file "smb2_qinfo_file.c"

   52       smb_ofile_t *of = sr->fid_ofile;

(dbx) next

t@40 (l@40) stopped in smb2_qinfo_file (optimized) at line 61 in file "smb2_qinfo_file.c"

   61       switch (qi->qi_InfoClass) {

(dbx) print of

dbx: Can't evaluate local variables in optimized functions

(dbx) 
I've tried gcc+gdb also (some time ago) and that was worse.

Ok, that's just generally being unable to deal with variables that have been optimized out of existence.  To deal with that I really am sort of in favour of having a separate toggle.  A good way would be to re-introduce teh SRCDBG flags bits, but leave your CUSERFLAGS on the end, so that you can use it to clobber -O.

$ dmake SOURCEDEBUG=yes CUSERFLAGS=-O0


Or whatnot.

I'll check on that - don't remember why that was added.

You're probably right that it wasn't needed.