[PATCH] New port: ia64-*-freebsd

[Marcel Moolenaar]

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