merged--can these go in target_resume()?
4. BFD problem--"Undefined symbol _aout_32_swap_exec_header_in".
+Believed to be fixed (fix not yet tested with GDB).
5. The linker complains about mfree and so on being multiply defined.
-As one version is in a library, this seems like a linker bug. But I
-think changing MMALLOC_LIB to MMALLOC in the .mh files is all that is
-necessary to fix it.
+Believed to be fixed (fix not yet tested).
6. i386_mach3_float_info and register_addr were undefined in the
link. I haven't investigated, but probably just another easy
7. I couldn't find mach_port_t in any of the headers in
/usr/include/*.h or /usr/include/mach/*.h (I think those are the two
-places I tried). Typedeffing it to void * in nm-m3.h seemed to work,
-but of course that's hardly an elegant solution.
+places I grepped; I don't know what headers I was actually getting).
+Typedeffing it to void * in nm-m3.h seemed to work, but of course
+that's hardly an elegant solution.
8. Implement the features which CMU gdb has which the main GDB does
not. This could be done by getting paperwork from CMU and merging
Speed up watchpoints by using debug registers, page table diddling (on
SunOS4, can call mprotect() in the inferior; on other machines can do
-something simpler), etc.
+something simpler), etc. Note that you need to detect a
+"fast-watchable expression" (i.e., if watching "*p", then either a
+change to the address pointed to by p or a change to p itself which
+causes the value of *p to change, is a watchpoint hit). It is
+possible we will also someday want extensions which are
+lower-level--"read from these addresses", "write to these addresses",
+etc., but there is no consensus about just how important these are and
+exactly what form they would take. There is a consensus that the
+existing watchpoint semantics should use hardware assists when
+available.
Update gdbint.texinfo to include doc on the directory structure and
the various tricks of building gdb.
projects / deliverable / binutils-gdb.git / blobdiff