6348 source-level debugging not quite working

Review Request #101 - Created Oct. 17, 2015 and updated

Information
Gordon Ross
illumos-gate
6348
Reviewers
general

6348 source-level debugging not quite working

Source-level debugging of usr/src/cmd/smbsrv/fksmbd

Issues

  • 2
  • 0
  • 0
  • 2
Description From Last Updated
We'd talked about this before, and I really don't agree with not optimizing at all when debugging. This changes (a ... Rich Lowe Rich Lowe
GSHARED is something we pass to ld. Neither of these are valid flags to ld. Whatever you're fixing by doing ... Rich Lowe Rich Lowe
Robert Mustacchi
Ship It!
Rich Lowe

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

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. Well... I say "source level debugging doesn't work".
    Do you have a better suggestion for fixing it?

  2. 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. It will take me some time to get you examples, but I can do that.

  4. 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. 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. Mostly, I just want to know what isn't working so I can see if there's a better way to fix it.

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

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. I'll check on that - don't remember why that was added.
    You're probably right that it wasn't needed.

Loading...