0xefbfe000) and kernel_start (normally 0xf0100000).
Things are unnecessarily (?) difficult because procfs is used to
access user addresses in the live-kernel case although we must have
access to /dev/mem to work at all, and whatever works for the
dead-kernel case should work in all cases (modulo volatility of
live kernel variables). We used the wrong range [0, kernel_start)
for user addresses. Procfs should only work up to VM_MAXUSER_ADDRESS,
but it bogusly works for reads up to the address 2 pages higher
(the user area, including the kernel stack, is mapped to where the
user area used to be (WTUAUTB)). Procfs can not work at all for
addresses between WTUAUTB and kernel_start.
Now we use procfs only to access addresses up to VM_MAXUSER_ADDRESS.
Higher addresses are translated normally using kvtophys(), so the
user ptd is used for addresses below the real kernel start (0xf0000000;
see INKERNEL()) and nothing is found WTUAUTB.
Strange accesses that cross the user-kernel boundary are now handled,
but such ranges are currently always errors because they necessarily
overlap the hole WTUAUTB.
Short reads are still not handled.
Correct translations would have been null. However, kstack was
the top of the kernel stack instead of the base of the kernel stack
like it was when the kernel exported it, so the area above the
kernel stack was mistranslated and the kernel stack was not
translated. This bug was depended on to compensate for the wrong
value of kstack - to read the pcb, instead of just using the address
of the pcb, we used the mistranslated address of kstack, which
happened to be the same (curpcb = kstack - 0x2000).
This area is simpler than it used to be now that the kernel stack
address is per-process. The code still seems to be more complicated
than necessary - the `found_pcb == 0' case seems to be unused.
gdb was cloned from the buggy version of kvm_uread() in libkvm and
had the same bugs. It looped endlessly on EOF and checked errno
without setting it in the lseek() error check. The first bug caused
gdb to loop endlessly for reads from addresses between the end of
the user area and the start of the kernel text. kvm_uread() should
not be used for addresses beyond the end of the user area, but is
due to bugs elsewhere.
the previous frame is in the usual place even for traps, interrupts
and syscalls in the kernel, because the assembly language stubs
don't change the frame pointer. The previous frame is just not for
the calling function. We may as well depend on this as on magic to
determine the trap frame address. The magic is in FRAME_SAVED_PC()
which elides the correct number of stubs (1) to go back to a pc that
matches the previous frame.
Removing fbsd_kern_frame_chain() fixes bugs in it. Xsyscall was
misspelled as _Xsyscall (gdb removes one leading underscore), so
the tf_syscall frame type was never found. This was harmless
because tf_normal works in all cases in fbsd_kern_frame_chain()
and Xsyscall is spelled correctly in fbsd_kern_frame_saved_pc()
where it matters. There were style bugs on almost every line,
starting with a primary indent of 7.
following "panic:" or "Fatal trap". `panicstr' is still printed,
although it is redundant if there is a valid message buffer and
incomplete if it contains `%'s. I think the awk command belongs
here and not in a script since a standard format with complete
messages is good for bug reports.
Implemented reading of %fs and %gs from core files.
Print weird floating point values better. We have to convert long
doubles to doubles here because of limitations and bugs in printf()
and floatformat_to_double() (long doubles aren't really supported
and naive converion to double causes exceptions). Conversion loses
information about weird formats (everything becomes a quiet NaN),
and printf() doesn't know about different types of NaNs anyway.
reference to the programming manual. Use this near-copy of the version
of hsuser.texinfo in contrib/libreadline instead of the stale near-copy
in contrib/gdb.
because 2 references to _initialize_kcorelow (the other one
from kvm-fbsd.c) resulted. This prevented gdb from working correectly.
delete kcorelow.c from XSRCS in the Makefile.
punning the pcb to an array of ints and using magic indices to
access values in it. This should prevent silent breakage from
changes in the pcb.
Supply 0 for unavailable registers instead of punning the tss to
an array of ints and using magic indices to access garbage values
in it. (The registers are in the pcb; there is nothing interesting
in the tss. This should change someday. At least for dumps, all
the registers should be saved, and common_tss is a good place to
put them.)
Removed ancient wrong (disabled) method for reading eip.
UPAGES layout.. it was entirely too comfortable with reading and writing
the U area before. I've changed it to use PT_GETREGS/PT_PUTREGS
ptrace ops instead of READ_U etc. The code to read the registers from
core dumps is a bandaid at best. It seems to have problems reading
core dumps from dynamic linked executables still, but at least static
dumps work.
I desperately need help from a gdb/bfd expert. :-) HELP!!
"%%" in format strings and tends to dump core for "%%st". I needed
"%%st" to fix the new gdb ...
Don't use the private version of strerror() either.
Use INTERNALLIB and INTERNALSTATICLIB instead of a private install
rules NOPROFILE and NOPIC. This is only slightly cleaner.
INTERNALLIB was previously only used in compatibility libraries
(libgnumalloc etc.) and INTERNALSTATICLIB was previously unused.
INTERNAL*LIB probably should be replaced by something like NOSTATICO
together with NO{STATICO,PROFILE,PIC}INSTALL.
by the -DNO_MMALLOC flag in gdb/Makefile.
The one thing we lose by doing this, AFAIK, is the possibility of using
mmap. Does anyone use that feature at all ?
2.2 candidate ?
files using the texi sources in /usr/src/contrib/gdb/gdb/doc.
I put a pointer to /usr/src/contrib/libreadline/doc into
Makefile.inc in the hope that the appropriate files would be
picked up.
This is based on /usr/ports/devel/gdb.
2.2 candidate ?
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
1) add Garrett Wollman's trap frame resolving mods
2) make the `proc' command (kernel debugging) really work
3) allow use of a pid with the `proc' command (previously you had to
provide the address of the proc structure)
Unfortunately, the `proc' command won't work while doing remote debugging.
alias `pcb_cr3' instead. That is still one alias too many, but is convenient
for me since I've replaced the tss in the pcb by a few scalar variables in
the pcb.
> * the gdb-4.13 of current (compiled and used under 2.0R) can not attach to my
> own processes (it works only then i'm root - else i get open failed - for my
> own processes)
how embarassing ! This turns out to be a bug in infptrace.c. Below
is a patch. Could some kind soul apply it ?
Submitted by: "Gary J." <garyj@rks32.pcs.dec.com>
of the linker to enforce linking of modules in command line order it is
not possible to link gdb shared with -lcompat.
*HACK ALERT*
Removed -lcompat from LDADD and bring in the necessary functions out of
libcompat as a source module until the linker can be fixed.
This might be useful for debugging applications that use a special LDT.
However, printing of all segment registers is currently broken.
Don't print "last exception: " before the FPU opcode and pc, etc. The
opcode and pc, etc., are for the last FPU _instruction_.
Pass the saved exception status word to print_387_status() so that the
exception(s) that caused or will cause a trap can be seen. The kernel
has supported this since 1.1 or before. The kernel still clobbers the
tag word if a trap occurs.
Remove unused null function clear_regs().
cvs is not being used effectively for gdb. Our old changes get clobbered
and our new changes are mixed with "vendor" changes in the same updates
so they will be difficult to untangle for the next release of gdb. The
revision logs get spammed for each release of gdb.
the wild, slippery orgy commence!
Gary Jennejohn, too studly for his own good, has finally come through with
the new, improved gdb 4.13. This gdb features:
o kgdb support - if this works (and I urge folks to test it), we can
finally purge the old and hateful version of kgdb from our source
tree.
o attach/detach support. See comments in README.FreeBSD for more
details.
o Well, it's newer. Our previous version was 4.11.
Comments and flames to gj, of course! :-)
Thanks, Gary. Much appreciated. The previous state of gdb/kgdb has been a
thorn in all of our sides for some time..
Submitted by: gj
This is a greatly pared down version of the full gdb-4.12, all the
config stuff has been removed and the supporting libraries have
been stripped to a minimum. This is a 1.1.5 only port, I'll do a
more complete port for 2.0 which will have all the config stuff
and will install the gnu support libraries as system libraries like
we do for readline.
There wasn't much point for 1.1.5 since only gdb would use them so I
went for saving space instead. For 2.0 I'll config all the
other gnu tools to use them as well.
The enclosed diffs implement printing of the floating point state for
the version of gdb-3.5 in 386BSD-0.0. I don't have gdb for 386BSD-0.1
but I've been told that it is also missing this feature.
The changes are small. Code to read the FP state from the kernel was
#ifdef'ed out, but it essentially works. Code to change the FP regs
is still #ifdef'ed out. It is close to working too. Printing of the
FP regs was broken because hard reg numbers were confused with stack
offsets.
4. The emulator does not handle FP errors right, and it does not
communicate the emulated FP state to the rest of the kernel, so
"info float" shows garbage.
