On Fri, Apr 30, 1999 at 05:01:20AM -0400, Thomas Bushnell, BSG wrote: > The first thing you need is fully ensymboled binaries. I am still > upset that the Debian packages don't have symbols, and I really really > want people to rethink this bug. But given that, you just have to > have ensymboled binaries.
Yes, I understand your concerns. However, if we would have unstripped binaries by default, the distribution would blow up a lot. Note that we have binaries for about 10 plattforms and 2200 packages. The distribution is taking several gigabytes to mirror already, and the bandwidth is also a concern. It's not good enough to strip the binaries at install time as a user option, because I would still have to d/l it over my $$$ link. Most people would not debug the software anyway. Under Linux, an strace is often all you need. We have debugging versions of the libraries. I would not object to have a special hurd-dbg package, which contains the Hurd unstripped. In fact, I already built such a thing once (it's 4.5 MB compressed), and it would be easy to change the rules files to produce it. Would this be a compromise? This would still leave the applications w/o symbols, though. > Then I would run things in a sub hurd to examine the bug. In that way > your machine will not blow up, because what ever thing causes the bug > will happen to the sub hurd, which will crash and burn, but not affect > the top level Hurd. I had troubles using a sub hurd when I tried it with older versions, but I will try again. Things have changed. > In that way you can see where things are stuck. In such an > environment it's usually pretty easy to find out what's blocked or > crashing, and then to track things back to find out which call caused > the problem. Then you start your subhurd again, attach a debugger to > the task that fails, and elicit the bug and watch it happen, and do > debugging as you would in any other kind of program. But wouldn't I need another terminal to attach a debugger from the parent Hurd? How do I observer the sub Hurd while it is running? I only havea single terminal, no network but PPP. Virtual Consoles could help :) Maybe I am just missing something. [...] > > More info: After interrupting, I can't start any more programs, although the > > shell still works. If I understood correctly, that's a problem with the exec > > server... > > Or the filesystem, more commonly. Yes, it's a bit flaky. Well may be the culprit. Thanks for all the information, Marcus -- "The purpose of Free Software is Free Software. The End and the Means are the same." -- Craig Sanders Marcus Brinkmann <[EMAIL PROTECTED]>
