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 24, 2005, at 2:26 PM, Daniel Jacobowitz wrote:
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?
Exactly. It is possible and not just academic for multi-threaded
applications to run out of backing store (e.g. by running into a
guard page or something along those lines). There's no way for
the processor to flush the dirty stacked registers if such is
needed and it would not be possible for the kernel to write them
out onto the backing store when creating a core dump.
That's where I get confused. How is
the data in the core file mapped onto the memory space?
I'm not quite sure I get your drift. Let me just answer what I think
you mean:
The backing store is nothing more than a second stack. The first being
the well-known memory stack onto which (stacked) local variables live.
The backing store grows upwards and the memory stack grows downwards.
So, in essence, it's a mmap'd region. Either created by the kernel when
the process is created, or created by the threading implementation.
In the core file the backing store is part of some loadable segment.
Either by itself or part of a larger block of memory.
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.
Agreed.
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.
It's not just the core file operation that needs augmenting. In theory
and practice all targets (ptrace, core, remote, etc) will need this.
That's why I figured that a new target object would be acceptable.
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.
Just FYI: I made a mistake. The number of dirty registers is not
expressed in register count, but in the amount of bytes they
occupy. This means that the amount of storage required to hold all
possible dirty stacked registers is 16KB (or 2048 registers and NaT
collections). This isn't nearly as bad a 128KB.
Sorry for the confusion.
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.
Correct.
I really recommend fixing your notes first and not making GDB support
this scheme.
I've thought about it. The point is that GDB already needs to support it
for Linux, so splitting up the work in such a way that FreeBSD
temporarily
has the same "limitations" as Linux seemed ideal. Not only is it
possible
to improve the overall core file support in FreeBSD, it also allows
Linux
to move away from the abstraction. In that sense, the abstraction is
gradually moved out of GDB. And as for any interim solution: there is
bound
to be some icky code for a while.
All I can say is that I'll think about it: The FreeBSD release schedule
is
now in my advantage, but getting binutils to grok a whole new kind of
core
notes may by itself turn out to be... euh... challenging... :-)
Anyway, that's enough out of me. I'll leave the rest to Mark and the
ia64 maintainers.
Thanks for comments. I appreciated it.
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net