This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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.

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.

So the answer to my above question is "you can't yet"?

Correct.


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'll be back"
	-- A. Schwarzenegger

--
 Marcel Moolenaar         USPA: A-39004          marcel@xcllnt.net


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]