Fw: Debugging plugins with gdb
Sending this to "gcc" since I got no help from sending it to "gcc-help" --- On Sun, 8/8/10, Jeff Saremi wrote: > From: Jeff Saremi > Subject: Debugging plugins with gdb > To: gcc-h...@gcc.gnu.org > Date: Sunday, August 8, 2010, 9:52 AM > I'd like to step into my plugin to > see if I can debug it. My plugin currently causes gcc to > crash. > Trying to use "break execute_x" command in > "add-symbol-file myplugin.so" but neither of them work. The > first one complains that "function not defined" and the 2nd > one says that "the address where .so has been loaded is > missing". > Try run with the arugments did not help either. After gcc > returns, it has unloaded the shared libraries. > I'd appreciate if anyone would share his experience in > successfully debugging a plugin. thanks > jeff >
Re: Fw: Debugging plugins with gdb
Daniel/Andrew thanks so much. I was using gdb version 7.1. So it understood deferred breakpoints but as long as I started gdb with something like ~/bin/gcc it never stopped in my function. As soon as I switched to running gdb on cc1, it worked! Now i can work on debugging the seg-fault i'm causing.
Beginner: Declarations do not show up when iterating through Gimple stmts
I wanted to go through declarations in a function and print them out so as to
get more familiar with them before being able to manipulate them.
I wrote this function as a plugin; it successfully writes out all statements
but mysteriouslty the declarations are missing. What am I missing? Is there a
different way to iterate through declarations?
thanks
jeff
static tree my_walk_stmt(gimple_stmt_iterator *gsi, bool *oprnds_handled,
struct walk_stmt_info *stmt_info)
{
int code;
gimple stmt = gsi_stmt(*gsi);
code = gimple_code(stmt);
switch(code)
{
default:
printf("Gimple code = %s\n", gimple_code_name[code]);
break;
}
*oprnds_handled = true;
return NULL_TREE;
}
static unsigned int execute_var_alias(void)
{
gimple_stmt_iterator gsi;
gimple_seq seq;
seq = gimple_body(current_function_decl);
for (gsi = gsi_start(seq); !gsi_end_p(gsi); gsi_next(&gsi))
{
gimple stmt = gsi_stmt(gsi);
walk_gimple_stmt(&gsi, my_walk_stmt, NULL, NULL);
}
}
Re: Beginner: Declarations do not show up when iterating through Gimple stmts
well, that explains it nicely. thanks
Guidance needed: hi-level steps to track an object until its destruction
I'm hoping someone here could take the time to outline what I need to do (i'm not looking for code but if you point me to some i'd appreciate it). I'd like to track an object from the it's created until it's destroyed (in C++). And then see if a certain method of it is called or not. To keep it short we can limit this to one function at the beginning of which an object gets created and at the end of it the object goes out of scope. And i'm guessing this can be done via one a pass at the right time. I guess before gimplification or being converted to RTL and such. Any input's appreciated. thanks jeff
Re: Guidance needed: hi-level steps to track an object until its destruction
Basile,
you fully understood what I was asking. And I think I understood that I may
have to rethink what I wanted to do since the effort is seemingly out-weighing
the benefits.
thanks again.
jeff
--- On Sat, 8/28/10, Basile Starynkevitch wrote:
> From: Basile Starynkevitch
> Subject: Re: Guidance needed: hi-level steps to track an object until its
> destruction
> To: "Jeff Saremi"
> Cc: gcc@gcc.gnu.org
> Received: Saturday, August 28, 2010, 1:05 PM
> On Thu, 2010-08-26 at 18:16 -0700,
> Jeff Saremi wrote:
> > I'm hoping someone here could take the time to outline
> what I need to do (i'm not looking for code but if you point
> me to some i'd appreciate it).
> >
> > I'd like to track an object from the it's created
> until it's destroyed (in C++). And then see if a certain
> method of it is called or not. To keep it short we can limit
> this to one function at the beginning of which an object
> gets created and at the end of it the object goes out of
> scope.
> > And i'm guessing this can be done via one a pass at
> the right time. I guess before gimplification or being
> converted to RTL and such.
>
>
> I am not sure that is easily feasible. I would believe it
> is impossible.
>
> Within the compiler (or inside a GCC plugin, or inside a
> GCC extension
> coded in MELT), you probably are able change/inspect C++
> classes & every
> other declaration any compiler is tracking. You are also
> able to find
> every occurrence of variables containing a pointer to such
> classes.
>
> However, you are apparently willing to track a single
> *instance* of such
> a class, and this instance is in the execution of the
> compiled program
> [not inside the compiler]. This means that you are able to
> deal with all
> the aliasing & pointer equivalence issues (a task known
> to be
> impossible). How can the compiler surely know that pointer
> p in [a
> particular instruction of] method YourClass::foo() is never
> (or
> sometimes, or always) pointing to the same instance -in the
> running
> process of the compiled program- as pointer q in method
> yourclass::bar()
>
> Or perhaps my English is so weak that I misunderstood you.
> If that is
> the case, apologies.
>
> Or maybe you want to instrument your compiler so that for
> every code
> emitted for method yourclass::gee() you add a first block
> which checks
> that the this reciever is not a given pointer.
>
> In other words & C++ parlance, you could (this is
> doable, but not
> trivial) hack the compiler so that at the start of every
> method (i.e.
> member function in C++) the equivalent of the following C++
> code has
> been magically added
>
> extern "C" YourClass* hunted_yourclass_pointer;
> extern "C" void some_error_routine(void);
>
> if (this == hunted_yourclass_pointer)
> some_error_routine();
>
> But I am not sure you want to do that.
>
> Cheers.
> --
> Basile STARYNKEVITCH
> http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile:
> +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes}
> ***
>
>
