Thank you for that very helpful info, Michael. I see what you mean about the extra flags. I haven't been compiling using "--with debug". Something strange happened this last time I compiled though: gdb just started working. I'm thinking it may have been a networking issue with my cluster, because that's the only thing I've changed between the compile that allowed me to debug and the one that didn't.
At any rate, it's working now. It didn't seem to make a difference if I used the "%with_cflags" bit. I took that part out and compiled again using "--with debug" and gdb is still working. It does still throw that error regarding "Missing separate debuginfos", but I'm able see a backtrace right away with no problem. Thanks again everybody for the enlightenment and the help! On Fri, Apr 29, 2016 at 12:55 PM, Michael Jennings <[email protected]> wrote: > > On Fri, Apr 29, 2016 at 7:38 AM, Michael Kit Gilbert <[email protected]> wrote: > > > Michael, thank you so much for offering your help! I created a Github > gist > > here with the output from my rpmbuild, which I did with the following > > command (from the root folder that had my other rpm folders in it e.g. > > BUILD, SOURCES, etc): > > > > rpmbuild -ba SPECS/slurm.spec -D '%with_cflags CFLAGS="-O0 -g3"' > > You also specified "--with debug" too, though, right? > > > It appears that the CFLAGS are in fact getting used, so maybe it is > actually > > compiling it the way it needs to, like you said. In regards to your > question > > about whether or not everything is getting stripped...this is my first > time > > doing a patch so I'm unfamiliar with exactly what you mean by that. > > They're showing up in the output, but they're not getting used. If > you look at a typical compilation line, like this one: > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../slurm > -I../.. -I /usr/include -O0 -g3 -pthread -fno-gcse -Wall -g -O0 > -fno-strict-aliasing -MT xtree.lo -MD -MP -MF .deps/xtree.Tpo -c > xtree.c -o xtree.o >/dev/null 2>&1 > > you'll notice that, while "-O0 -g3" definitely appears, so does "-g > -O0," and the latter appears later in the options. The latest flags > specified are the ones that win, so -g is overriding -g3. Shouldn't > make a huge difference, though; debugging symbols should still wind up > in the final product. > > Everything in the build looks good, so you should be able to > successfully debug the resulting binaries once you install the > packages you built. > > To check this, use "nm -Bal /usr/sbin/slurmd" and look at the output; > it should look something like this: > > ... > 0000000000000000 a xtree.c > 00000000004683ec T xtree_common > > /home/mej/local/slurm-15.08.9/build.mezz/BUILD/slurm-15.08.9/src/common/xtree.c:487 > 0000000000468098 T xtree_delete > > /home/mej/local/slurm-15.08.9/build.mezz/BUILD/slurm-15.08.9/src/common/xtree.c:409 > 0000000000467d4c T xtree_depth > > /home/mej/local/slurm-15.08.9/build.mezz/BUILD/slurm-15.08.9/src/common/xtree.c:273 > 0000000000467c7f T xtree_depth_const > > /home/mej/local/slurm-15.08.9/build.mezz/BUILD/slurm-15.08.9/src/common/xtree.c:236 > 0000000000467cf1 T xtree_depth_const_node > > /home/mej/local/slurm-15.08.9/build.mezz/BUILD/slurm-15.08.9/src/common/xtree.c:258 > ... > > and so forth. If you get "no symbols," then the symbol table has been > stripped from your binary. If you get symbols but no filename/line > number info, then the debugging information has been removed or was > not compiled in to begin with. > > Keep in mind that, while "file" can tell you if a binary is or is not > stripped, that's not enough to determine whether or not it has > debugging information in it. You need to look at the symbols > themselves for that. > > HTH, > Michael > > -- > Michael Jennings <[email protected]> > Senior HPC Systems Engineer > High-Performance Computing Services > Lawrence Berkeley National Laboratory > Bldg 50B-3209E W: 510-495-2687 > MS 050B-3209 F: 510-486-8615 >
