This is the mail archive of the gcc-patches@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: Designs for better debug info in GCC


On Nov  9, 2007, Michael Matz <matz@suse.de> wrote:

> static inline int foo(int i)
> {
>   return i-1;
> }

> int foobar(int j)
> {
>   return foo(j+2);
> }

> int main(int argc, char **argv)
> {
>   return foobar(argc);
> }
> ------------------------------------

> And similar examples.  Depending on circumstances the formal argument 'i' 
> of "foo" might be optimized away.

With the design I've proposed, it is possible to compute the value of
i, for the end result is live, which ensures that the inputs used to
compute i are not completely optimized away.  This means at any point
in the execution of foo it is possible to compute i based on the
inputs (argc or j) or the outputs (the return values of foo, foobar
and main), no matter how much inlining takes place.  Now, it is
perfectly possible that foo is completely optimized away, such that no
instruction remains in the scope in which i is live.  In this case,
it's debatable whether i still remains, but we could still emit debug
information for it if we wanted to.

> If you want to use systemtap to show the actual arguments for all
> calls to foo, even the inlined ones, then you somehow have to make
> sure that the value of 'i' itself is not optimized away.

As I wrote before, I'm not aware of any systemtap bug report about a
situation in which an argument was actually optimized away.  I
wouldn't go as far as stopping the optimization just so that systemtap
can monitor the code.  I'm not working on changing optimization to
improve debugging, I'm working on fixing debug information such that
it matches optimizations that occur.

> at which point you have to force the value of 'i' being live, if you
> want to be sure that systemtap works in all cases.

I don't want to be sure of that.  At least that was not the problem I
was asked to solve.  And, indeed, it's not solvable without disabling
optimizations.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


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