(This is a sort of manual thing, and it just wasn't being done here.
All this binfile handling should probably be refactored to wrap some of
this detail away...)

I assume what happened here is that when we added the debuginfo root
prefix business, and expanded the search for vmlinux, that we never did
that for modules; but not sure.  Anyway, this fixes the module search so
it is similar to searching for vmlinux.

(Also update INSTALL a bit.)

When loading vm_area_structs, we used to return the arch-specific
vm_page_prot field.  That field is arch-specific, meaning it is ready to
be loaded into a PTE.  The non-arch-specific field is vm_flags.  So, we
really want to return the non-arch-specific since we're at the semantic
layer.  If this causes problems, we can add an arch-specific field, too.

Make it clear that Stackdb is distributed under GPLv2+, i.e., v2 or
any later version.  All of the source files already say this, but the
COPYING file said GPLv2 only.

Also, update the copyright years.

Also, say "Stackdb" rather than "VMI."

We were effectively assuming virtual memory in os-process targets was
contiguous... ouch.  Somebody (me) got a little too excited about just
calling the base target!

The fix for os_process_write is a little unfortunate, though.
Basically, we assume that if we can resolve all the v2p mappings and
read a byte from each page, that the page is present.  So we actually do
all those checks before writing anything.  These checks of course are
racy if the VM is not paused, but right now it's the best we can do.
The only other solution would be to hack the hypervisor page protection
bits, which would be super-heavyweight.  And we're not going to do that
anytime soon!

    /*
     * NB: QEMU's gdb stub removes all breakpoints on '?', so we have to
     * only call this on target attach!  We have to trust our status as
     * TARGET_PAUSED when we call gdb_pause(), if it succeeds.  This
     * must also be the gdb client's default behavior, although I don't
     * think I saw this in the protocol docs.
     */

(And of course gdb stubs always send stop statuses on breakpoint
exception or whatever... so strictly speaking, we don't need to rely on
this call at all.)

Look for a limit of stack frames with the same IP addr, and abort
if we see more.

This should be configurable, but it's not right now.

It makes the compiling complain under non-xen environment. And I did not
used any function call in that header.

Update the configure.in and Makefile.in to compile and intall pingpongmonitor

I did not use any function from the target_xen_vm.h. But if you
compile it in the qemu environment, there is a compilation error
for lacking xen support.

Somehow the actual HAVE_CLIPSSRC def stuff didn't get in here, argh!

Not sure why this wasn't there...

I needed %gs and %crX, so I pull those from QEMU's QMP via
the 'info registers' command.  But rather than actually parsing
the JSON responses, I just look for a few specific strings to grab
the register values.  Well, I neglected to account for asynchronous
notifications, and those were causing the register reads to "fail".
So, now we just keep reading until we see what we expect.  Still
could be racy cause we read to a fixed buffer, but it's really
unlikely.  Still no time to write a JSON message parser.

Ok, so we print out iovec contents and control msg contents too.
If I just login/logout, those sendmsg/recvmsg calls seem to have
bogus control msg data, but maybe it's an empty buffer with just
a length.  My handcoded example proves it works.  We don't decode
control message data yet, though.