Re: [PATCH] New port: ia64-*-freebsd

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Jul 15, 2005 at 11:20:46AM -0700, Marcel Moolenaar wrote:
> On Jul 14, 2005, at 7:16 PM, Daniel Jacobowitz wrote:
> >So, it treats the annex as a memory pointer and returns the contents of
> >memory there.  Why?  And why is this a useful generic implementation?
> 
> Yeah, that's a bit tricky. Here's why:
> 
> The stacked registers that are flushed, live in memory below the
> address pointed to by the BSPSTORE register. The stacked registers
> that are dirty would be flushed to memory between the values of
> BSPSTORE (bottom) and BSP (top) if and when they are being flushed.

Unless there isn't room, right?  That's where I get confused.  How is
the data in the core file mapped onto the memory space?

> I figured that from an API point of view it's safer to access the
> dirty registers by their index or offset relative to BSPSTORE, and
> not by their absolute memory address, because their corresponding
> memory address is unreal. I can change the backing store pointer
> (i.e. BSPSTORE) and then flush the dirty registers. So, tying the
> dirty registers to their would-be memory address seemed "wrong".
> Hence, the offset is the offset relative to BSPSTORE.

Sure... though documentation of this would be good.

> However when the dirty registers need to be accessed as if they
> were flushed, as needs to be done on Linux, then we need to know
> to value of BSPSTORE so that we can map the relative offset to
> an absolute memory location. For this reason I use the annex.
> To support cross-debugging when gdb runs on a 32-bit host, I
> cannot pass BSPSTORE by value (sizeof(void*) < sizeof(CORE_ADDR)).
> So, I pass it by reference. Hence the indirection.

This does not seem like anything that needs or wants a generic
implementation.  I think we will need to arrange for the target to
override and augment the core file operations, so that this can be in
an ia64-specific file - probably, an ia64-linux or ia64-freebsd (it's
not clear to me which from your description) specific file.

> There's just one slight problem: the number of dirty registers is
> variable, but bounded. Unfortunately the upper bound is rather
> high: 16383. This yields a worse-case memory footprint of 128KB :-/
> (8 bytes per register and NaT collection).
> I think that on average the number of dirty registers is something
> like 128. I doesn't really look like a good idea to create the 128KB
> of memory for the worst-case when 1KB would be sufficient on
> avarage.

This I know how to handle; it hasn't been implemented yet, but the
optional/target-available registers interface will allow you to create
the necessary number of dirty registers in the regcache.  I'm not sure
I agree that they belong there, but I don't know enough about it to
judge.

> >>From your description abov it sounds like these ought to be in their
> >own core file note anyway; why have they ended up in "memory"?
> 
> That's currently how Linux works and it's also currently how FreeBSD
> creates the core files. Linux cannot do it any other way, because it's
> all abstracted by the kernel on live processes and if gdb doesn't know
> the difference between flushed and dirty stacked registers, you cannot
> dump the dirty stacked registers to a core file anywhere else then where
> they would be when they were flushed.
> 
> On FreeBSD the note isn't yet created because that requires a bit of
> work and we had the plans to revamp the core file notes anyway (due
> to threading). So, I decided to first get the port contributed and
> then work on how best to deal with the dirty stacked registers. This
> then could be part of a larger (cross-platform) revamp of how FreeBSD
> creates core files, which would also result in a rather large set of
> changes to binutils.
> 
> Anyway: since some targets work with the abstraction, there need to
> be a couple places where accessing dirty registers need to be mapped
> to memory references. This may change in the future.

Except FreeBSD, it sounds like, supports cases where they couldn't be
mapped unambiguously to memory.

I really recommend fixing your notes first and not making GDB support
this scheme.

Anyway, that's enough out of me.  I'll leave the rest to Mark and the
ia64 maintainers.

-- 
Daniel Jacobowitz
CodeSourcery, LLC