This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] New port: ia64-*-freebsd
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?
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? 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.
>>> 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.
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.
>> 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.
Mark