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

[Daniel Jacobowitz <drow at false dot org>]

On Thu, Jul 14, 2005 at 07:08:09PM -0700, Marcel Moolenaar wrote:
> >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.

Thank you!  This needs to be described in the source somewhere.  I'd
like to see a more descriptive name for TARGET_OBJECT_DIRTY, also,
though I don't have any advice - right now it would be a good place to
stick a dirty hack.  Or dirty laundry.

> >The corelow.c implementation of TARGET_OBJECT_DIRTY looks pretty
> >sketchy for target-independent code.
> 
> What exactly do you mean?

+    case TARGET_OBJECT_DIRTY:                                                                          
+      {                                                                                                
+       ULONGEST addr;                                               
+       addr = *(ULONGEST*)annex + offset;                        
+       if (readbuf)                                                    
+         return (*ops->deprecated_xfer_memory) (addr, readbuf, len,                                    
+                                                0/*read*/, NULL, ops);                                 
+       if (writebuf)                                         
+         return (*ops->deprecated_xfer_memory) (addr, writebuf, len,
+                                                1/*write*/, NULL, ops);
+       return -1;                                                                                      
+      }                                                                                                
+

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?
>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"?

> 
> >You have a lot of non-GNUish formatting issues - mostly the pesky
> >spacing rules.
> 
> No doubt. I'm not used to the GNU formatting :-)

You did better than most people not used to it can manage :-)

-- 
Daniel Jacobowitz
CodeSourcery, LLC