lkml.org 
[lkml]   [2006]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [discuss] Re: [PATCH 2/3] reliable stack trace support (x86-64)
    Date
    On Thursday 18 May 2006 11:37, Jan Beulich wrote:
    > >>> Andi Kleen <ak@suse.de> 16.05.06 19:05 >>>
    > >
    > >On Tuesday 16 May 2006 18:06, Jan Beulich wrote:
    > >> >>> Andi Kleen <ak@suse.de> 16.05.06 17:13 >>>
    > >>
    > >> On Tuesday 16 May 2006 16:21, Jan Beulich wrote:
    > >> >> These are the x86_64-specific pieces to enable reliable stack traces.
    > >> >> The only restriction with this is that it currently cannot unwind
    > >> >> across the interrupt->normal stack boundary, as that transition is
    > >> >> lacking proper annotation.
    > >> >
    > >> >It would be nice if you could submit a patch to fix that.
    > >>
    > >> But I don't know how to fix it. See my other mail
    > >
    > >which mail?
    >
    > Reply to Ingo (with you on cc) regarding patch 1/3. Just saying that I
    > don't know much about expressions here.
    >

    Hmm, maybe we can find somebody who does. But then they would
    first need to be implemented in the unwinder anyways, I guess.
    Could be nasty agreed.

    > >> - I have no experience with expressions, nor have I ever seen them in
    > >> use.
    > >
    > >I remember Jim Houston used a hack of just loading the old stack into a
    > > register and defining that as a base register in CFI. I guess i would be
    > > willing to trade a few moves for that (should be pretty much free on a
    > > OOO CPU anyways) You think that trick would work?
    >
    > I don't think that would, because without CONFIG_DEBUG_INFO none of the
    > preserved registers get saved, hence there's no register to use for this.
    > Thus the price would not only be a move, but also a save/push and a
    > reload/pop.

    Three instructions? We might be still able to afford that.

    push/pop is probably not needed because the stack frame will be already
    set up (ok possibly after a few instructions, but a small window might be
    tolerable)

    > >> >> +#define UNW_PC(frame) (frame)->regs.rip
    > >> >> +#define UNW_SP(frame) (frame)->regs.rsp
    > >> >
    > >> >I think we alreay have instruction_pointer(). Better add a
    > >> > stack_pointer() in ptrace.h too.
    > >>
    > >> I could do that, but the macros will have to remain, as they don't
    > >> access pt_regs dierectly, so I guess it'd be pointless to change it.
    > >
    > >UNW_PC() is instruction_pointer(&frame->regs), isn't it?
    >
    > Yes. But the intention is that the user of UNW_PC doesn't need to know any
    > details of what fields frame has (i.e. the parameter of UNW_PC must only be
    > frame), so you can't replace it with instruction_pointer().

    Maybe I'm dense but I still don't get - frame has a pt_regs so why
    isn't the caller allowed to know about that fact?

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

    \
     
     \ /
      Last update: 2006-05-18 13:24    [W:0.028 / U:0.532 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site