Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tcf-dev] Question about the step-over logic. 
Hi Xavier,

> First, I would like someone to confirm if my understanding is good.

Yes, it is good.

> Now my question comes when the stepped-line has a call to a function
> that has no debug info.

In such case the code relies on stack crawl logic (aka crawl_stack_frame()) to compute CFA.

> ... that would be a problem because ext->step_frame_fp == info->fp.

Yes, if a non-leaf function frame has 0 size, it would cause ambiguity. However, this is not normal. Non-leaf function frame must at least have space to store return address.

> Conceptually, I have trouble understanding what CFA should be at the
> first instruction of a function.

CFA, by definition, should be same at any instruction of a function. However rules to compute CFA can be different at different places in the function.

Regards,
Eugene

-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Xavier Pouyollon
Sent: Tuesday, April 15, 2014 8:33 AM
To: tcf-dev@xxxxxxxxxxx
Subject: [tcf-dev] Question about the step-over logic.

Hi,

I'm trying to understand how the line-step-over logic works. Here is my
current understanding (see below).
First, I would like someone to confirm if my understanding is good.
Then, I have a few questions when we try to step-over a function that
has NO debug_informations.
Thanks.

First, let's consider we have debug-info / debug-frames generated.

When we start a step-over:
in runctrl.c:
             if (ext->step_cnt == 0) {
                 StackFrame * info = NULL;
                 ext->step_frame_fp = 0;
                 if (get_frame_info(ctx, STACK_TOP_FRAME, &info) < 0)
return -1;
==> We get the current "fp" for the current function.

Can someone confirm:
    "fp" means "frame address" aka CFA (canonical frame address)
     So the value retrieved for the ctx is the one described by the CFA
rule matching the instruction pointer.:
    cfa = 00(r3) (for example using dwarfdump -f)

Then the stepping of the line range starts. When we are out-of the
range, it means:
a) Either we have finish the step-over.
b) Either we are in a function called by the stepped line.

When out-of-range:
We get the "fp". If the computed fp is the same as previous, we are in
case a). Easy, done.
If the the computed "fp" is different, we are in case b) and we retrieve
the caller @ in step_bp_addr, resume the target.

Now my question comes when the stepped-line has a call to a function
that has no debug info.
We end-up at the very beginning of the function.
We go into the "stack crawl" code. Either the one from open-source or a
custom-one.

I'm currently writing a custom-one for a an architecture that works with
way:
Let's say the stack-pointer is r3.
jarl <foo>

When in <foo>
r3 has NOT changed.
r31 acts as LR and contains the return @.

The prolog will create a "frame pointer". But we are currently stopped
at the first instruction of the function.
So prolog has NOT been executed.

What should we return to (get_frame_info(ctx, STACK_TOP_FRAME, &info)
for info.fp ?
Can we return 0 as "fp" in the following case ?
     - we have no debug_information.
    -  we are stopped at the beginning of the function (so prolog has
NOT been executed).

Returning 0 as "fp" (aka cfa) will ensure that the following code in
runctrl.c will pass.

(step_cnt > 0)
                 if (get_frame_info(ctx, n, &info) < 0) return -1;
                 if (ext->step_frame_fp != info->fp) {
             .... retrieve caller, set step_bp_addr ....
             }

I've taken a look at what the compiler generates at the beginning of
function:
cfa = 0(r3).

So if I return r3, which was my first idea, that would be a problem
because ext->step_frame_fp == info->fp.
Or is cfa = 0(r3) a compiler bug ? I have this rule as the first
instruction of any function.

Conceptually, I have trouble understanding what CFA should be at the
first instruction of a function.

Thanks !


_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

Back to the top