Keith Owens <[EMAIL PROTECTED]> writes:
> Nobody has been concerned enough about the backtraces on i386 and
> x86_64 to add the required unwind data to the kernel for those
> platforms. If you want to extract the dwarf data from a kernel
> compiled with -g, include the dwarf data in the running k
On Mon, 17 Jan 2005 09:30:17 + (GMT),
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
>Hmmm, interesting, then -g compiled Linux kernel should also be useable,
>with perhaps some tweaks to kdb to decode these frames correctly, right?
kdb on i386 uses heuristics to guess at what parameters have be
Sorry, it was a "red herring", namely my module's Makefile still had
"-mregparm=0" in CFLAGS, so that is why kdb showed it's arguments
correctly (and then paniced on the way out).
So we still have to deal with DWARF2 data then... Ok, will look into it.
Kind regards
Tigran
On Tue, 18 Jan 2005, Ti
On Tue, 18 Jan 2005, Tigran Aivazian wrote:
I already solved this paricular problem. And the solution is (but don't tell
me you knew it, for then why didn't you tell anyone) simply --- compile the
kernel with -g and that includes enough debug information to be able to
decode the stack content co
On Tue, 2005-01-18 at 11:25 +, Tigran Aivazian wrote:
> However, this highlighted a more serious problem in the x86_64 kernel (or
> more likely in the kdb patch) --- the kernel compiled with -g panics when
> you try to return from kdb after hitting a breakpoint. This is a bug and
> I'll inv
On Mon, 17 Jan 2005, H. Peter Anvin wrote:
Or does kdb not have a client at all? (If so, I have no sympathy for it.)
Peter, it was very easy for you to call my emails "rants" and "not even
funny" but the above statement is displaying complete ignorance of what
kdb actually is :) So, instead of "
> Seems like the unwinder should be running client-side, like it does on
> kgdb. Or does kdb not have a client at all? (If so, I have no sympathy
> for it.)
kdb runs 100% in the kernel.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Andi Kleen wrote:
To be fair there isn't a nice library for it on x86-64. There
is libunwind on IA64, but afaik nobody ported it to x86-64 yet.
Just various projects have their own private unwind
implementation. The kernel including KDB has always lived with
imprecise backtraces and no argument pr
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Tigran Aivazian wrote:
>> On Mon, 17 Jan 2005, Arjan van de Ven wrote:
>>
Actually, having cc'd Linus made me think very _carefully_ about what I
say and I went and checked how the userspace does it, as I couldn't
believe that such fine
Tigran Aivazian wrote:
On Mon, 17 Jan 2005, Arjan van de Ven wrote:
Actually, having cc'd Linus made me think very _carefully_ about what I
say and I went and checked how the userspace does it, as I couldn't
believe that such fine piece of software as gdb would be broken as well.
And to my surprize
On Mon, 17 Jan 2005, Tigran Aivazian wrote:
>
> So, this means there is no way for kdb on x86_64 to show the parameter
> values for each function in the back trace. Any chance of changing the
> ABI/x86_64 to do the right (i.e. passing via stack like on i386) thing
> now? Then kdb would automa
Hi Andi,
On Mon, 17 Jan 2005, Andi Kleen wrote:
The ABI supported way is to read the DWARF2 unwind tables. For that
you would a dwarf2 reader. gdb does that in user space, and libgcc2
also does it for exception unwinding. IA64 has an in kernel dwarf2
reader library (and ia64 kdb uses it), although
Tigran Aivazian <[EMAIL PROTECTED]> writes:
>
> When I said "2-3 weeks of work" I didn't fully realize the complexity
> of the problem. It is actually more like several months of research
> work and then (most likely) coming to the conclusion that the code to
> simulate the cpu (by disassembling th
On Mon, 17 Jan 2005, Arjan van de Ven wrote:
Actually, having cc'd Linus made me think very _carefully_ about what I
say and I went and checked how the userspace does it, as I couldn't
believe that such fine piece of software as gdb would be broken as well.
And to my surprize I discovered that gdb
On Mon, 2005-01-17 at 09:30 +, Tigran Aivazian wrote:
> I cc'd Linus as I cannot believe he agreed with allowing such an
> optimization to be a default and standard thing accepted by the Linux
> kernel. (But I may be wrong, especially since Linus isn't particularly
> fond of kdb anyway :)
I
On Sat, 15 Jan 2005, H. Peter Anvin wrote:
It depends on the architecture ABI. This is the case for the i386
ABI, but definitely *NOT* for x86-64.
Yes, precisely. The ABI/x86_64 defines this behaviour explicitly. However,
that would mean the ABI was designed without giving thought to debugging
16 matches
Mail list logo
