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 25, 2005, at 12:31 PM, Mark Kettenis wrote:
From: Marcel Moolenaar <marcel@cup.hp.com>
Date: Mon, 25 Jul 2005 10:58:30 -0700
On Jul 25, 2005, at 10:35 AM, Daniel Jacobowitz wrote:
On Mon, Jul 25, 2005 at 10:32:27AM -0700, Marcel Moolenaar wrote:
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.
No, that's not what I mean.
Here and further below you think I'm talking about the concept of the
target object. I'm not. I'm talking specifically about the corefile
implementation you included.
That implementation reads from an address in memory to find the
registers. If there's no room for them in memory, where the heck are
they, and how can you find them by reading from memory?
They're lost. If the core file is created because the process ran
out
of backing store, then you're pretty much hosed. There's no way you
can get a stack trace because the stacked registers you'll need
first
are the dirty ones and those aren't in the core file. This is the
fundamental problem that Linux has.
Damn, I'm somehow lost. Are we talking about Linux or FreeBSD here?
Both. Currently the FreeBSD kernel "flushes" the dirty stacked registers
onto the backing store (i.e. writes it out to the process' memory before
the memory map is dumped) because there's no immediate support in the
toolchain (both binutils and gdb) for having them "out-of-band" in
notes.
This is a temporary measure until the toolchain has been enhanced. If
and
when the toolchain is enhanced, I'll fix the FreeBSD kernel and the
statements above will only apply to Linux.
In any case it seems a rather nasty problem. It seems that the kernel
should somehow be able to realise it ran out of backing store, and
stick the stacked registers somewhere else in the core file. This is
what you had in mind for FreeBSD isn't it?
Yes. Since we talked about revamping the core file notes prior to
FreeBSD 5.3, I did some swift finger-based arithmetic and came to
the conclusion that as a first implementation it would be acceptable
(for me :-) that this corner case would not be finished.
BTW, to get into details: I'll have the kernel dump the dirty stacked
registers in a note unconditionally. In other words, even if the core
dump doesn't seem to be caused by backing store overflow. The reason
for this is that even if the backing store could be written to, the
kernel may actually destroy valuable state. Think for example about a
multi-threaded application for which the memory stack grows down
towards the backing store and the register stack grows upwards to the
memory stack. Suppose also that the stacks are not protected from each
other by a guard page. Then, writing the dirty stacked registers may
cause the kernel to overwrite the memory stack even in the situation
that the running process did not overflow either stacks (due to the
lazy nature with which the processor flushes dirty registers).
Better safe than sorry...
Then, if GDB knew how to
find those dirty registers, it'd be able to do proper backtraces. But
then the user wouldn't be able to tell why the program crashed. It's
probably better to be able to provide a useful backtrace though.
Agreed. One can infer that a process dumped core due to an overflow of
the backing store. The faulting instruction would typically be the alloc
or flushrs instruction and the faulting address would typically be the
value of BSPSTORE and would typically point to the first byte of the
page
after the backing store itself (this last is probably not that easy to
figure out because one typically does not know the extend of the backing
store, nor can one fully trust that BSPSTORE points inside the backing
store). But other than that: there are some telltale signs.
*snip*
The proper way to push this out of GDB is (in my opinion) what I did
for StackGhost on OpenBSD/sparc. GDB expects to find a .wcookie
(psuedo-)section in the core file. Filling this section is the job of
platform-dependent code in BFD. For ELF core files the most logical
way would be to provide a note which is converted into that section by
BFD. That's how I would do it for .wcookie in ELF core files anyway.
But since OpenBSD still uses old NetBSD-style core files, this isn't
implemented yet. This whole approach is handled very similar to the
way normal register are handled in core files.
Interesting. I'll keep that in mind. I don't know the details about
StackGhost, but it might be something to guide me.
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... :-)
Actually it's quite easy.
Challenge extended...
... Challenge accepted :-)
I think the code that implements NetBSD core file handling is a good
example of how to do this.
Yes, you mentioned this before. There was just one problem I ran into:
The PID and LWPID are concatenated into a 32-bit integral and passed
on the GDB as the "pid". On FreeBSD this cannot be done, because
both PID and LWPID are already 32-bit by itself. As such, the BFD to
GDB interface for extracting the thread ID needs to be modified if
we want to do it right.
To be exact: elfcore_make_pid() in binutils/bfd/elf.c needs to be
fixed.
Anyway: let's not jump ahead. I haven't studied the code lately
and things may be much easier now or I may understand the code
better than before.
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net