linux-parisc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: Randolph Chung <randolph@tausq.org>,
	linux-parisc@vger.kernel.org, Kyle McMartin <kyle@mcmartin.ca>
Subject: Re: [PATCH] parisc: add CALLER_ADDR{0-6} macros
Date: Tue, 27 Oct 2009 14:41:46 +0100	[thread overview]
Message-ID: <20091027134146.GA2223@p100.box> (raw)
In-Reply-To: <4AE67BED.8040705@tausq.org>

* Randolph Chung <randolph@tausq.org>:
>> +unsigned long return_address(unsigned int level)
>> +{
>> +	struct unwind_frame_info info;
>> +	struct pt_regs r;
>> +	unsigned long sp;
>> +
>> +	/* initialize unwind info */
>> +	asm volatile ("copy %%r30, %0" : "=r"(sp));
>> +	memset(&r, 0, sizeof(struct pt_regs));
>> +	r.iaoq[0] = (unsigned long) current_text_addr();
>> +	r.gr[2] = (unsigned long) __builtin_return_address(0);
>> +	r.gr[30] = sp;
>> +	unwind_frame_init(&info, current, &r);
>> +
>> +	/* unwind stack */
>> +	++level;
>> +	do {
>> +		if (unwind_once(&info) < 0 || info.ip == 0)
>> +			return 0;
>> +		if (!__kernel_text_address(info.ip)) {
>> +			return 0;
>> +		}
>> +	} while (info.ip && level--);
>> +
>> +	return info.ip;
>> +}
>> +
>
> Can you show an objdump of this function once it is compiled? I suspect  
> the stack pointer initialization here is not reliable.

> Ideally unwind_frame_init is called with the frame address in gr[30].  
> With a big struct like pt_regs on the stack, the sp initialization might  
> be quite far from the actual frame address.
>
> The unwind_once() code uses like heuristics to try to recover from  
> inaccurate stack pointers (by aligning and stepping the frame 64 bytes  
> at a time) but that is really a brute force guess.
>
> I realize I used a similar construct in traps.c, but even there I think  
> it doesn't work reliably.

Hi Randolph,

I agree, that those kind of implementations may not always be reliable.
Nevertheless, I started off with a copy of your code, but it didn't
worked at all. I assume due to some compiler-trickery to include the
static local functions in other functions it does work in traps.c 
nevertheless.

I did sucessfully tested the patch I submitted here, both in 32- and 64-bit.

Below is the disassembly of the code which you asked for...

Helge


Disassembly of section .text.return_address:

00000000 <return_address>:
   0:	08 03 02 41 	copy r3,r1
   4:	6b c2 3f d9 	stw rp,-14(sp)
   8:	08 1e 02 43 	copy sp,r3
   c:	6f c1 04 80 	stw,ma r1,240(sp)
  10:	68 67 04 00 	stw r7,200(r3)
  14:	08 02 02 47 	copy rp,r7
  18:	68 66 04 08 	stw r6,204(r3)
  1c:	08 1a 02 46 	copy r26,r6
  20:	68 65 04 10 	stw r5,208(r3)
  24:	68 64 04 18 	stw r4,20c(r3)
  28:	08 1e 02 44 	copy sp,r4
  2c:	34 65 00 50 	ldo 28(r3),r5
  30:	34 19 00 00 	ldi 0,r25
  34:	08 05 02 5a 	copy r5,r26
  38:	e8 40 00 00 	b,l 40 <return_address+0x40>,rp
  3c:	34 18 03 b0 	ldi 1d8,r24
  40:	68 67 00 60 	stw r7,30(r3)
  44:	eb 80 40 00 	blr r0,ret0
  48:	08 00 02 40 	nop
  4c:	68 64 01 40 	stw r4,a0(r3)
  50:	68 7c 03 a0 	stw ret0,1d0(r3)
  54:	03 c0 08 bc 	mfctl tr6,ret0
  58:	34 64 00 10 	ldo 8(r3),r4
  5c:	0f 80 10 99 	ldw 0(ret0),r25
  60:	08 04 02 5a 	copy r4,r26
  64:	e8 40 00 00 	b,l 6c <return_address+0x6c>,rp
  68:	08 05 02 58 	copy r5,r24
  6c:	08 04 02 5a 	copy r4,r26
  70:	e8 40 00 00 	b,l 78 <return_address+0x78>,rp
  74:	34 c6 00 02 	ldo 1(r6),r6
  78:	8f 80 60 80 	cmpib,> 0,ret0,c0 <return_address+0xc0>
  7c:	34 1c 00 00 	ldi 0,ret0
  80:	48 7c 00 20 	ldw 10(r3),ret0
  84:	87 80 20 68 	cmpib,= 0,ret0,c0 <return_address+0xc0>
  88:	08 1c 02 5a 	copy ret0,r26
  8c:	e8 40 00 00 	b,l 94 <return_address+0x94>,rp
  90:	08 00 02 40 	nop
  94:	87 80 20 40 	cmpib,= 0,ret0,bc <return_address+0xbc>
  98:	48 7c 00 20 	ldw 10(r3),ret0
  9c:	87 80 20 40 	cmpib,= 0,ret0,c4 <return_address+0xc4>
  a0:	48 62 3f d9 	ldw -14(r3),rp
  a4:	84 c0 20 30 	cmpib,= 0,r6,c4 <return_address+0xc4>
  a8:	08 04 02 5a 	copy r4,r26
  ac:	e8 40 00 00 	b,l b4 <return_address+0xb4>,rp
  b0:	34 c6 3f ff 	ldo -1(r6),r6
  b4:	87 80 7f 95 	cmpib,<= 0,ret0,84 <return_address+0x84>
  b8:	48 7c 00 20 	ldw 10(r3),ret0
  bc:	34 1c 00 00 	ldi 0,ret0
  c0:	48 62 3f d9 	ldw -14(r3),rp
  c4:	48 67 04 00 	ldw 200(r3),r7
  c8:	48 66 04 08 	ldw 204(r3),r6
  cc:	48 65 04 10 	ldw 208(r3),r5
  d0:	48 64 04 18 	ldw 20c(r3),r4
  d4:	34 7e 00 80 	ldo 40(r3),sp
  d8:	e8 40 c0 00 	bv r0(rp)
  dc:	4f c3 3f 81 	ldw,mb -40(sp),r3


      reply	other threads:[~2009-10-27 13:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-25 21:48 [PATCH] parisc: add CALLER_ADDR{0-6} macros Helge Deller
2009-10-27  4:49 ` Randolph Chung
2009-10-27 13:41   ` Helge Deller [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091027134146.GA2223@p100.box \
    --to=deller@gmx.de \
    --cc=kyle@mcmartin.ca \
    --cc=linux-parisc@vger.kernel.org \
    --cc=randolph@tausq.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).