This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] New port: ia64-*-freebsd
On Jul 14, 2005, at 5:01 PM, Daniel Jacobowitz wrote:
I don't know anything about ia64, or much about FreeBSD, so I will
refrain from a thorough review. You'll need Kevin or Jeff to look over
it eventually (see MAINTAINERS). I have a bunch of comments about the
patch anyway, mostly dealing with the bits I couldn't make sense of - I
just wanted to do my part against the patch sitting unread for
months...
:-)
Don't worry: Mark has contacted me off-list. We'll go through it
as time permits.
On Tue, Jul 05, 2005 at 12:51:04PM -0700, Marcel Moolenaar wrote:
Gang,
It took a while, but the legal preconditions have recently been
met and I'm delighted to present you with the long awaited port
of GDB to FreeBSD/ia64.
It's not very useful as a single jumbo patch - especially since you
didn't explain any of what it was doing.
I see. It helps to know what people like to see explained. This
avoids that I ramble on about trivialities while skipping the
complicated or non-intuitive bits.
You added bits to the remote protocol; those must be documented in the
manual (and, generally, discussed beforehand). Are there any stubs
which use them?
Good point about the documentation. I'll dig into it. As for whether
there's a stub that uses it: yes, the FreeBSD kernel.
The comment on TARGET_OBJECT_DIRTY says "see ia64-tdep.c", which has
basically no comments explaining what it does, or why it is necessary
for FreeBSD when it isn't for GNU/Linux.
A quick explanation then:
Stacked registers are either dirty or flushed when it comes to
accessing them. Stacked registers that are flushed have been
written to the backing store by the processor -- they are in
the target's memory. Stacked registers that are dirty are still
in the processor. They end up on the kernel's stack of the
corresponding process whenever there's a kernel context switch.
Linux abstracts this and allows them both to be read and written
the same way. FreeBSD doesn't abstract this. The reason
FreeBSD doesn't abstract it is because it is not always possible
to do so, nor is it always beneficial to do so.
So, in order for gdb to handle all possible failure modes, it
needs to be aware of the difference so that it can access the
registers accordingly.
A typical example of a failure mode that cannot be debugged with
abstraction, is a core file created when the backing store overflows.
The kernel will not be able to move the dirty stacked registers
in the core file, because there's no room for it (there's no space
on the backing store where they would normally go). They need to
be written into the core file as a note (like the general registers)
and fetched seperately.
NATIVE_XFER_DIRTY is not necessary; the BSDs all use target vector
inheritance now as far as I know, so you can override it that way.
Similarly tm-fbsd.h is not necessary any more.
Ok, thanks. I'll dig into that as well.
The corelow.c implementation of TARGET_OBJECT_DIRTY looks pretty
sketchy for target-independent code.
What exactly do you mean?
You have a lot of non-GNUish formatting issues - mostly the pesky
spacing rules.
No doubt. I'm not used to the GNU formatting :-)
Thanks for the feedback,
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net