linux-kernel - Re: MIPS RT debug support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <473D8560.5060500@third-harmonic.com>
Date:	Fri, 16 Nov 2007 06:56:16 -0500
From:	john cooper <john.cooper@...rd-harmonic.com>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	Tim Bird <tim.bird@...sony.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	john cooper <john.cooper@...rd-harmonic.com>
Subject: Re: MIPS RT debug support

Steven Rostedt wrote:
> IIRC, only CALLER_ADDR0 is actually used (I've found that the others are
> mostly unreliable).

I seem to recall more use was made of __builtin_return_address(n)
for 0 < n in the past compared to the current code.  Likely for
shallow frames the 0 < n calls were potentially returning invalid
data which is why they currently appear to be commented out.

Rather than lobbying to fix __builtin_return_address(), replacing
it with a primitive which works in all cases seems an easier
solution.  That stub stack frame really does provide useful debug
information.  In the case of ARM I simply walked the stack.  Worst
case in that vintage of the code was four iterations so the overhead
was in the noise.  That same solution could easily be applied to
other architectures.

> It's been several years since
> I've worked on mips (I'd love to do it again, if someone sends me a box!,
> hint hint).

Concerning a MIPS board, if no freebies should arrive you
might want to dig up a linux footprint friendly version of
a Linksys WRT54GS.

-john

-- 
john.cooper@...rd-harmonic.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/