Re: [PATCH v2 3/4] arc: Add GNU/Linux support for ARC

[Simon Marchi <simark@simark.ca>]

On 2020-06-15 7:13 p.m., Shahab Vahedi wrote:
> On Thu, May 14, 2020 at 11:09:08AM -0400, Simon Marchi wrote:
>> On 2020-04-28 12:04 p.m., Shahab Vahedi via Gdb-patches wrote:
>>> +/* Initialization specific to Linux environment.  */
>>> +
>>> +static void
>>> +arc_linux_init_osabi (struct gdbarch_info info, struct gdbarch *gdbarch)
>>> +{
>>> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>>> +
>>> +  if (arc_debug)
>>> +    debug_printf ("arc-linux: GNU/Linux OS/ABI initialization.\n");
>>> +
>>> +  /* If we are using Linux, we have in uClibc
>>> +     (libc/sysdeps/linux/arc/bits/setjmp.h):
>>> +
>>> +     typedef int __jmp_buf[13+1+1+1];    //r13-r25, fp, sp, blink
>>> +
>>> +     Where "blink" is a stored PC of a caller function.
>>> +   */
>>> +  tdep->jb_pc = 15;
>>
>> I don't really understand this, could you dumb it down a bit for me?
> 
> In advance, I appologize if my explanation is not right on the spot
> or is too verbose. I am not 100% sure what is not clear, so I try to
> explain as much as I can.
> 
> If you mean why "tdep->jb_pc" is 15 and what the comments mean, then:
> 
> fp    -> Frame Pointer register
> sp    -> Stack Pointer register
> blink -> Branch and LINK register (acts like a "return" register)
> 
> blink register is set (implicitly) when "bl @name_of_fuction" instruction
> is used. It will point to the instruction that comes after "bl" (branch
> and link). e.g.:
> 
>   0x100: add r0, r1, r2
>   0x104: bl @galaxy_far_away     # pc=@galaxy_far_away; blink=0x108
>   0x108: add r3, r4, r5
> 
> a simple "j(ump)  blink" will return from the function.
> 
> -----
> 
> The layout of "__jump_buf" looks like:
> 0..12:   stored registers r13, r14, ..., r25
> 13:      stored fp
> 14:      stored sp
> 15:      stored blink
> 
> This is how the "calling" convention in ARC saves the
> registers before switching the frame to another function.
> 
> I hope it is clear now.

Ah ok, and that value is the offset of the PC in the buffer.  I see that the
comment above the definition of the jb_pc explains that, I might have missed
it the first time.

Thanks,

Simon