On 10/06/2013 01:13 PM, Michael Stone wrote: > On Sun, Oct 06, 2013 at 11:33:17AM -0700, Octavio Alvarez wrote: > You seem to be creating overcomplicated possibilities. If we were to > create a -dbg package, here's what would be different:
Only in my particular case, which inolves timeout and timer_create; but please see the big picture. The whole point of this discussion is not to fix my particular case, but to explain why it could have been important and useful to an outsider to have the coreutils-dbg package. My case might was an extremely simple one, and even with that, resulted in overcomplication. > Syscall param timer_create(evp) points to uninitialised byte(s) > at 0x4E36E1A: timer_create@@GLIBC_2.3.3 (timer_create.c:83) > by 0x402607: settimeout (timeout.c:144) > by 0x4022C5: main (timeout.c:468) > Address 0x7ff0006b0 is on thread 1's stack > > instead of: > > Syscall param timer_create(evp) points to uninitialised byte(s) > at 0x4E36E1A: timer_create@@GLIBC_2.3.3 (timer_create.c:83) > by 0x402607: ??? (in /usr/bin/timeout) > by 0x4022C5: ??? (in /usr/bin/timeout) > by 0x5278994: (below main) (libc-start.c:260) > Address 0x7ff0006b0 is on thread 1's stack That was my expected result, yes. > Does that make it any less necessary to look at the coreutils source? No, but it surely makes it easier because it grounds away any uncertainty. > FWIW, if you build from the debian package, you could run the relevant > program out of the build directory, where it is not stripped. No need to > "hack it" to strip the symbols; alternatively, you can build with the > nostrip build option if you want to create a .deb. A-ha! I didn't know that, thanks! Had I known I'd gone to that since the beginning. These are the kind of stuff that would just make it slower for me (and who knows how many others) than just being able to install the package and be done with *this part* of the debugging process. > But, as pointed out > above, this isn't really going to tell you anything that a quick grep > would not--timer_create is only called once in the timeout program.. Sure, I did it that way after finding out coreutils-dbg was not available, and I found it unnecessary; most importantly, I did not have enough certainty about what I was doing. Also, I wanted to breakpoint inside timeout with gdb to make sure I was following the correct execution path, but this turned out not possible at first glance, hence, by bump on this report. >> Each step that I have to learn as I go has a set of variables, and >> each variable makes the problem more complex until I the time and work >> needed is greater than my interest. I was initially willing to debug >> and attempt a fix but now I'm not sure anymore. > > See above. Now that you have the additional information that would be > present in the -dbg package, does it help? It helps a lot. It gives certainty to outsiders when debugging. There is little *effective* difference, but it importantly lowers my contribution barrier of entry. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
