gdb still isn't working

gdb still isn't working

Post by Charles Hedri » Tue, 21 Apr 1992 11:23:04



I've been trying to get gdb working.  The problem is more subtle than
I had first thought.  It worked fine up to 0.95b.  However as of 0.95c
and 0.95c+, it stopped working.  My main problem is that breakpoints
don't work.  It's hard to be sure, but it looks like when the program
comes to a breakpoint, typically it gets segmentation fault, though
sometimes I also see the program terminate with signal 5 (breakpoint).
At first I assumed that this was because of changes in the header
files, such as a.out.h, but I've built 0.95c+ with the old a.out.h and
that doesn't fix it.

At this point I can't even tell whether the problem is in gdb or the
kernel.  I'm hoping the folks who did gdb and ptrace in the first
place can look into this, since trying to learn the innards of gdb,
ptrace, and signal handling could take quite some time...  I'd
be happy to test any fixes.

By the way, even in the working kernel, gdb doesn't trap errors.  When
a program blows up, it's supposed to trap to the debugging, so you can
look around.  It doesn't do that.  I think die, in trap.c, needs to
check whether the program is being debugged or not, and do something
different.

Finally, gdb seems to lose control over the program being debugged
if my shell is tcsh.  It works only with bash.

 
 
 

gdb still isn't working

Post by Linus Benedict Torval » Tue, 21 Apr 1992 17:51:43



Quote:>I've been trying to get gdb working.  The problem is more subtle than
>I had first thought.  It worked fine up to 0.95b.  However as of 0.95c
>and 0.95c+, it stopped working.

Yes, it's a bug in the kernel.  It was there already in 0.95b and
earlier, but those had a (buggy) workaround that made it work for most
things anyway.  The problem was that not all kernel mode -> user mode
changes checked the error conditions, so things like breakpoints didn't
work too well.

My personal version handles this correctly (as well as doing some other
things in a cleaner manner), but I'm not quite ready for a new release
yet.  I could make YAAR (yet another alpha-release) or just mail
interested parties the fixes needed - mail me if you're interested, and
depending on the number of messages I get I'll make it a new release.

Here's a preview of 0.96 (* means already implemented):

* truncate/ftruncate/fchmod/fchown system calls

* io-bitmap allowing user processes controlled access to io-ports (thanks to
  obz - needed for X)

* mmap for /dev/mem - (thanks to obz) allows X etc to use the frame buffers

* the signal-handling fixes needed for gdb

- multiple shared libraries (pmacdona)

- cleaned up special files: partly implemented already

and probably some other minor fixes.

                Linus

 
 
 

gdb still isn't working

Post by Linus Benedict Torval » Thu, 23 Apr 1992 08:15:10



Quote:> [ trace not working in gdb ]

>My personal version handles this correctly (as well as doing some other
>things in a cleaner manner), but I'm not quite ready for a new release
>yet.  I could make YAAR (yet another alpha-release) or just mail
>interested parties the fixes needed - mail me if you're interested, and
>depending on the number of messages I get I'll make it a new release.

Ok, the response seems to make a new pre-release appropriate: I have
uploaded "pre-0.96.tar.Z" to tsx-11 and nic.

Here is what the pre-release contains:

- truncate/ftruncate/fchmod/fchown system calls

        note that there aren't any library functions for these, so they
        aren't very useful yet...

        [f]truncate needed a change in the logic of the internal
        truncate VFS call - anybody that has any nonstandard filesystem
        probably needs to look it up.

- io-bitmap syscalls giving root-processes access to selected io ports
  from user space.  There is a "ioperm()" system call that lets the
  process select which ports it wants to enable/disable (all ports
  disabled as default) as well as a (standard sysv?) ioctl interface
  that X uses.

        again, no library stubs, but it allows things like reading and
        setting the cmos clock without using /dev/port, as well as
        control over the VGA registers...

- mmap for /dev/mem

        more things needed for X...

- the signal-handling fixes needed for gdb

        These aren't yet complete: serial lines still send signals under
        interrupts that can result in problems (ie ptrace doesn't
        correctly get them), but that's pretty unlikely (and will be
        fixed in the final 0.96).  Breakpoints should work etc..

- multiple shared libraries

        Up to 6 simultaneous shared libraries/process: the patches were
        originally by pmacdona, but they were heavily changed by me, and
        I think they work in a more natural manner now.  One user-level
        change is that the libraries are now checked for read and
        execute permissions for safety-reasons.

- cleaned up special files.

        read/write/ioctl no longer has special-case code: it is all
        handled with tables to functions.  This will mean that the SCSI
        patches won't patch in quite cleanly into 0.96: you'll need to
        add the code that sets up the functions.

        Again: device drivers and vfs-filesystem hackers need to look
        into the changes, although they are pretty logical (earlier
        versions just didn't implement all the vfs-routines)

        Note that the vfs-code for select is still not used: select is
        hardcoded for the devices it supports right now.

- ptrace() has a new interface

        as gdb for versions < 0.95c don't work on the new version, and
        gdb won't work very well at all on 0.95c[+], there was no reason
        not to break ptrace.  Thus 0.96 has a new calling convention for
        ptrace, and the old ptrace library function no longer works.
        I'm including the new ptrace library function at the end of this
        post.

- mount() takes 4 arguments, and checks that only the super-user can
  mount/umount things.

        Happily this shouldn't break any old binaries.

- some general cleanups

I've made the pre-release available only as pure source code: no diffs,
no binary. The reason is that most people that needed this release want
it for the gdb-fixes: and they should have no problem recompiling the
kernel.  Others just have to wait for the real 0.96.

Changes that are NOT in this pre-release, but which I hope to have in
the real 0.96:

        - more include-file cleanups - I'm still working on these

        - the wd8003 driver and hopefully some other parts of biro's
          config.

        - select() using the vfs-tables.

And possibly bugfixes that people find in this pre-release...

                Linus

---------- library ptrace.c (wants gcc-2.1) ----------
#define __LIBRARY__
#include <time.h>
#include <unistd.h>

int ptrace(int request, int pid, int addr, int data)
{
        long ret;
        long res;

        if (request > 0 && request < 4)
                (long *)data = &ret;
        __asm__ volatile ("int $0x80"
                :"=a" (res)
                :"0" (__NR_ptrace),"b" (request), "c" (pid),
                 "d" (addr), "S" (data)
                : "si","bx","cx","dx");
        if (res >= 0) {
                if (request > 0 && request < 4) {
                        errno = 0;
                        return (ret);
                }
                return (int) res;
        }
        errno = -res;
        return -1;

Quote:}

 
 
 

gdb still isn't working

Post by Tommy Tho » Fri, 24 Apr 1992 20:34:12



Quote:>    fixed in the final 0.96).  Breakpoints should work etc..

Why do we/you use this stupid way of naming releases? It's just major
confusion that different versions of releases can have the same or
almost the same name. Why not do it simple: a version number uniqly
identifies a set of sources. Even the tiny patch to 0.95c should
be considered as a new version. If we hadn't been so eager to change
version names from 0.12 to 0.95, there would still be enough headroom
to 1.0.

It's ok to use subnumbering like 0.95c to denote alpha tests, but
subsubnumbering like 0.95c+ is too much. Whats this for a number 'pre 0.96',
what's wrong with 0.95d, and if patches to it are small and make a stable
system, go ahead call it 0.96.

/Tommy
--
/Tommy Thorn, another LPF member. Terminate software patents.

Are *you* sure that *your* program isn't already covered by patents?

 
 
 

gdb still isn't working

Post by Jim Winstead J » Mon, 27 Apr 1992 10:18:35




>>        fixed in the final 0.96).  Breakpoints should work etc..

>Why do we/you use this stupid way of naming releases?

>It's ok to use subnumbering like 0.95c to denote alpha tests, but
>subsubnumbering like 0.95c+ is too much. Whats this for a number 'pre 0.96',
>what's wrong with 0.95d, and if patches to it are small and make a stable
>system, go ahead call it 0.96.

I agree, but I don't think the problem has been the time it's taken to
go from 0.95 to 0.96, but rather the silly names like 0.95c+ and
0.95c++, which should have been 0.95d and 0.95e.

Related to this, Linus and I have agreed to basically split the
version numbering of the root and boot floppies.  The major number
(0.95, 0.96, 1.00) will agree, but after that, kernel updates will
have letter prefixes (0.96a, 0.96b), and the root image will be
updated with a minor number (0.96.1, 0.96.2, etc).  This will let
Linus and I keep slightly different schedules, and hopefully eliminate
some confusion.  (Where's the 0.95c++ root image?)
--
Jim Winstead Jr. (CSci '95)    | "Catch a fish!"
Harvey Mudd College            |  -Geddy Lee,

Disclaimer: Mine, not theirs!  |   January 20, 1992

 
 
 

1. gdb - why the HECK isn't it working?!

I've tried using the gdb debugger to debug a long-running program that seems
to periodically crash for some unknown reason.  I ran gdb on the program (which
was, btw, compiled with gcc with the -g flag for debugging) and told it the
core dump file to go for.  gdb comes back at me with a segmentation fault in
itself!  I can't run this thing from within the debugger because it runs for so
long, like it ran for 13 hours before crashing this morning and I'm not running
it from the AFS so I know that's not it.  I'm eyeballing the code now for
problems but it would make it a heckuvalot easier if the only blasted debugger
I can use would WORK like it's supposed to!

If anyone can tell me why it's not working and/or can give me instructions on
how to do it in case I'm by chance doing something wrong, please respond via
email preferrably.

Thanks in advance,

---
        _______________________
       /-------888888888-------\                     ______
 /--------------------------------------------------/   ===\----
#-------------------------------------_________________________/
##_\*************###########--------'             \==========/
  \_\*************#######---------'                `________(  ----#
     `**************######------'

         `*************######----`           Computing Services
     ___    `*************#######---:=====#    UNC-Charlotte
    /O O\                                        Charlotte, NC, USA
--oo0-U-0oo---------------------------------------------------------------
  PROGRAM \'pro--.gram\ [n] A magic spell cast over a computer allowing
    it to turn one's input into error messages.  [vt] To engage in a
    pastime similar to banging one's head against a wall, but with fewer
    opportunities for reward.
--------------------------------------------------------------------------

2. Xtank

3. I don't understand why this code isn't working

4. Whereis static libX11.a ?

5. samba's nmdb isn't working - why?

6. Software induced reboot

7. Printing ain't working for crap...HOWTO isn't much help...

8. Error While creating shared libs on freebsd using gcc

9. PPP works if Net card isn't installed

10. HELP: my X font server isn't working

11. Term isn't working.

12. My DNS isn't working

13. seagate travan tape WAS working now isn't!