This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: offsets of stack variables with optimizations enabled in GCC


> It isn't clear what you are doing.
>
> Note that the stabs format (from dbxout) is not sufficiently flexible to
>   fully describe an optimized executable.  So the debug info we emit is
> a compromise.
>
> dwarf2/3 can do better, but we don't have full support for all of its
> features (e.g. location lists) yet, and so internally we don't have as
> much info as we'd like.
>
> Internally to gcc, the stack offsets must obviously be correct,
> otherwise we would not be able to emit correct code.
>
> When optimizing, a variable does not necessarily live in the stack slot
> allocated to it.  It might be sometimes in a register and sometimes in
> the stack slot.  When it is in the stack slot, it doesn't necessarily
> have the value that you expect it to have from reading the source,
> because various optimizations could have been applied to it.
> --
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
>

Hi, Jim

Sorry for the confusion. I want to identify the accesses to stack
variables dynamically ( I am using a simulator). That is, given an
address to access in runtime, I should be able to tell whether it is a
stack variable access. I modified GCC a little
bit and dumped the offsets to SP (FP) of stack variables following the
example of dbxout.c . Then I load the offsets into the simulator so that
it can track accesses to stack variables dynamically according to the Sp
(FP) and the offsets.

This works well if I don't enable optimizations. After optimizations, the
dumped offsts seem confusing to me. They are quite different from the ones
without optimizations. I am using GNUPro (xscale-elf-gcc). Without
optimizations, the offsets are all negative. With optimizations, the
offsets become all positive.

The function prologue generated by GNUpro looks like: (thumb code)

push {r4, r7, lr}
mov r7, sp
sub sp, #12

I think the offsets dumped with opt. enabled are still offsets to SP or
FP. My best guess is that the offsets dumped without opt. are the offsets
before the third instruction shown above (stack space allocation), while
the offsets dumped with opt. are the offsets after the third instruction.
If it is true, why is there such an inconsistancy?

Sure, GCC internally should have the correct offsets for stack variables.
That's what I want. I think I can use the similiar method demostrated in
dbxout.c to extract the information? The important thing is what the
offset is relative to, should be SP(FP), but SP(FP) at which program
point? I hope there is a fixed poiont ...

Thanks a lot

Tao



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]