Interpreting stack frame

2009-03-20 Thread Peter Leist
Hello,

I just started hacking around with the gcc internals, so apologize if
this is a noob
question:

How can I interpret the stack frame of the current_function? That
means, how can
I tell what is stored at the location FP+xxx. If that is not (easily)
possible, it would
help if I can somehow determine the type of data stored at that
location (i.g is that
a reference to a variable or the contents of a variable).

I tried to tackle the problem inside expand_prologue and via
var-tracking, but to be
honest I don't have enough knowledge about gcc internals to handle the problem.

Any help or hints would be greatly appreciated.

thanks,
peter


Re: Interpreting stack frame

2009-03-23 Thread Peter Leist
On Fri, Mar 20, 2009 at 4:54 PM, Ian Lance Taylor  wrote:
> Peter Leist  writes:
>
>> How can I interpret the stack frame of the current_function? That
>> means, how can
>> I tell what is stored at the location FP+xxx. If that is not (easily)
>> possible, it would
>> help if I can somehow determine the type of data stored at that
>> location (i.g is that
>> a reference to a variable or the contents of a variable).
>
> Stack slots can be shared by different variables, so I'm not sure there
> is a coherent answer to this.

I understand that, but at a given point in the program flow the assignment
of stack slot to a variable should be fixed.

> That said, look at assign_stack_local and
> assign_stack_temp in gcc/function.c.

Thanks for the pointer, but it seams these functions are responsible only
for arguments, not for local variables (at least assign_stack_local).

What I try to achieve is: Given the frame pointer for a function X, how can I
tell which of the used stack frames hold what data (at a given time in
the program flow).
To be more exact, I would like to know that before a call is taken. I want to
tell for every stack slot of the *calling* function if the data in that slot is
passed to the called function as a reference or not

Every debugger should be able to tell that, or am I wrong? Can I probably
extract the information from debug data? I've seen a reference to
x_stack_slot_list
in assign_stack_local.c but that doesn't seem to do the trick.

Thanks,
Peter


Re: Interpreting stack frame

2009-03-23 Thread Peter Leist
On Mon, Mar 23, 2009 at 5:52 PM, Andrew Haley  wrote:
> Peter Leist wrote:
>>
>> I understand that, but at a given point in the program flow the assignment
>> of stack slot to a variable should be fixed.
>
> Should it?  We do some very drastic transformations in gcc, sometimes
> coalescing variables, sometimes eliminating them altogether, and
> sometimes creating new ones which have no equivalent in the source.
> This is all business as usual for an optimizing compiler.

Ok, I think I expressed my goals unclear. I do not want to link a slot 1:1
to a source-code variable. It is clear that such a relation does not exist
in an optimized code.

Maybe I have to ask the other way around: How can I find out
which stack slots of the current function may get changed be a called
function. Or in other words: At each call of an other function, I want to
know which stack slots (not variables) are passed as arguments via reference.

>> Every debugger should be able to tell that, or am I wrong? Can I probably
>> extract the information from debug data?
>
> Yes, but as I explain above the information is not going to be complete.

As stated above, I probably don't need complete information.

Peter


Emit jump insn in function prologue

2009-04-24 Thread Peter Leist
Hi all,

can I use emit_cmp_and_jump_insns while creating the function prologue/epilogue?
If I try, I always get an error at runtime

func.c:33: internal compiler error: in make_edges, at cfgbuild.c:354

I think this is because the jump doesn't get an JUMP_LABEL associated to it.
Is there an other way at this pass to add loops to the code?

thanks,
peter