Ship It!

usr/src/Makefile.master (Diff revision 2)

Show all issues

We'd talked about this before, and I really don't agree with not optimizing at all when debugging.  This changes (a great deal) the code we output, under the guise of just retaining symbol information.

1. 

   Gordon Ross Oct. 18, 2015, 12:31 a.m.

   Well... I say "source level debugging doesn't work".
   
   Do you have a better suggestion for fixing it?

2. 

   Rich Lowe Oct. 18, 2015, 12:39 a.m.

   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 :)

3. 

   Gordon Ross Oct. 18, 2015, 12:45 a.m.

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

4. 

   Josef Sipek Oct. 20, 2015, 2:05 p.m.

   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.

5. 

   Gordon Ross Oct. 20, 2015, 6:09 p.m.

   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.

6. 

   Rich Lowe Oct. 20, 2015, 7:11 p.m.

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

7. 

   Gordon Ross Oct. 21, 2015, 6:31 p.m.

   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.

8. 

   Rich Lowe Oct. 21, 2015, 11:17 p.m.

   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.

usr/src/Makefile.master (Diff revision 2)

Show all issues

GSHARED is something we pass to ld.  Neither of these are valid flags to ld.

Whatever you're fixing by doing this is certainly broken, but this isn't where you should stuff -g to fix it.

1. 

   Gordon Ross Oct. 18, 2015, 12:32 a.m.

   I'll check on that - don't remember why that was added.
   
   You're probably right that it wasn't needed.