Interpreting stack frame
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
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
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
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