Hey Tom, You are right. Don't tell me "I know, I am always right!" ;-) Following the script. Next step, how can I install it in /opt/e17? Which file do I need to modify?
Script:
class Eo_step(gdb.Command):
def __init__(self):
gdb.Command.__init__(self, "eo_step", gdb.COMMAND_OBSCURE)
def invoke (self, arg, from_tty):
# While libeo is not reached, we step into
while gdb.solib_name(gdb.selected_frame().pc()).find("libeo.so")
== -1:
# step by one assembly instruction, no print
gdb.execute("stepi", False, to_string=True)
# While we are in libeo or in an unknown function, we step into
while (gdb.selected_frame().function() == None) or
(gdb.solib_name(gdb.selected_frame().pc()).find("libeo.so") != -1):
# step by one assembly instruction, no print
gdb.execute("stepi", False, to_string=True)
print "Stopped at file " +
gdb.selected_frame().find_sal().symtab.filename+ "line " +
str(gdb.selected_frame().find_sal().line) + " function " +
str(gdb.selected_frame().function())
Eo_step()
Daniel
On 12/11/2012 01:20 AM, Tom Hacohen wrote:
> Hey Daniel,
>
> I found this in python.c in the gdb source tree:
> /* Implementation of gdb.solib_name (Long) -> String.
> Returns the name of the shared library holding a given address, or None.
> */
>
> static PyObject *
> gdbpy_solib_name (PyObject *self, PyObject *args)
>
> So just use gdb.solib_name...
>
> I just skimmed through the file, maybe there's more there I've missed, sounds
> like exactly what you are looking for.
>
>
>
>
>
> On Mon, Dec 10, 2012 at 9:18 AM, [email protected]
> <mailto:[email protected]> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Tom,
>
> 1. I will check it, maybe just print line and which file
> 2. I don't find how to get the library name. Sure it will be
> easier with the library.
> 3. I understand the point but for the moment I don't have a
> solution. I will investigate when time is with me (not so english,
> this sentence).
>
> If you find something on your side, tell me.
>
> Daniel
>
>
> On 12/10/2012 12:44 AM, Tom Hacohen wrote:
>> Hey Daniel,
>>
>> Good thing that it works and I'm happy you improved it so fast,
>> but I still have a couple of comments:
>> 1. "print "You reached the function " +
>> str(gdb.selected_frame().function())" - It's probably better to
>> change it to fit the gdb style of info messages better. It
>> doesn't look like something you'd see out of gdb.
>> 2. "(yes I stay with that, it seems easier than with the
>> library)" - It just means you are doing something wrong as if you
>> have a properly stripped binary there's no information about
>> "eo.c" so it just won't work. Furthermore, I don't understand how
>> it is easier, both are just a single test and it's a matter of
>> just accessing a different property.
>> 3. "if (self.priv_current_line != self.priv_prev_line) or
>> (str(self.priv_current_symtab) != str(self.priv_prev_symtab)):" -
>> If I understand it correctly it seems that you are looking until
>> the line has changed. This isn't good because if for example you
>> do: "eo_do(obj, SET_A, get_some_number())" it'll fail as it'll
>> get into the second function, and not the eo call. I don't know,
>> maybe that's what you expect it to do, and then it's fine, but
>> then the second loop kinda doesn't make sense...
>>
>> If you use the so name you can do something as simple as:
>> 1. stepi until we get into libeo.so.
>> 2. stepi until we get out of libeo.so.
>>
>> Very simple, very easy. No variables, state or anything.
>>
>> What do you think?
>>
>> --
>> Tom.
>>
>>
>> On Sun, Dec 9, 2012 at 12:39 PM, [email protected]
>> <mailto:[email protected]> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi Tom,
>>
>> It works with stepi.
>> The stepping process consists now in two phases:
>> - stepping until we are no more in the the caller function
>> - stepping while function name unknown or still in Eo.c (yes
>> I stay with that, it seems easier than with the library)
>>
>> It now supports Eo with and without symbols.
>>
>> Code is following. Let's see soon in SVN.
>>
>> Daniel
>>
>> class Eo_step(gdb.Command):
>> def __init__(self):
>> gdb.Command.__init__(self, "eo_step", gdb.COMMAND_OBSCURE)
>>
>>
>> def invoke (self, arg, from_tty):
>> self.priv_prev_line = gdb.selected_frame().find_sal().line
>> self.priv_prev_symtab =
>> gdb.selected_frame().find_sal().symtab
>> while True:
>> # step by one assembly instruction
>> gdb.execute("stepi", False, to_string=True)
>> # While under same code line
>> self.priv_current_line =
>> gdb.selected_frame().find_sal().line
>> self.priv_current_symtab =
>> gdb.selected_frame().find_sal().symtab
>> if (self.priv_current_line != self.priv_prev_line)
>> or (str(self.priv_current_symtab) != str(self.priv_prev_symtab)):
>> break
>>
>> while True:
>> # step by one assembly instruction
>> gdb.execute("stepi", False, to_string=True)
>> # While under unknown code or Eo code
>> symbolNotFound = True
>> if (gdb.selected_frame().find_sal().symtab != None
>> and gdb.selected_frame().find_sal().symtab.filename ==
>> "lib/eo/eo.c"):
>> symbolNotFound = False
>>
>> if (gdb.selected_frame().function() != None) and
>> (symbolNotFound == True):
>> print "You reached the function " +
>> str(gdb.selected_frame().function())
>> break
>> Eo_step()
>>
>>
>>
>> On 12/06/2012 05:14 PM, Tom Hacohen wrote:
>>
>> Just use "stepi", that one goes inside. "step" goes to
>> the next line of
>> code and if there is none inside it just steps to the
>> next line. I'm
>> actually trying to look for a command that does what I
>> said we need in the
>> first place (and that you've implemented to some extent),
>> which just goes
>> on until the next line with debug information. Anyhow,
>> now you can
>> implement exactly that, just walk into eo_do_internal
>> until the next line
>> with debug info, easy.
>>
>> Btw, there's another thing we need, and that's probably a
>> way to stop on an
>> eo_do with a specific op code, like we break on
>> evas_object_resize at the
>> moment. It's not a big deal because this can be achieved
>> with breaking on
>> the internal functions, but still, I think it'll make our
>> lives easier.
>> This one is probably easier to make.
>>
>>
>> On Thu, Dec 6, 2012 at 11:30 AM, [email protected]
>> <mailto:[email protected]> <
>> [email protected]
>> <mailto:[email protected]>> wrote:
>>
>> When I compile without -O and -g, gdb behaves like
>> with stripped
>> library, i.e doesn't try to enter the function. Maybe
>> I do something wrong.
>> Tom, can you try it on your computer?
>>
>> Thank you
>> Daniel
>>
>> On 12/06/2012 12:45 AM, Tom Hacohen wrote:
>>
>> Compile Eo in release mode: remove -O0/-g from
>> your CFLAGS, re-configure
>>
>> Eo
>>
>> (efl tree I assume) with --with-profile=release
>> (or something like that,
>> just check the configure options, it's easy) and
>> make && make install.
>>
>> You
>>
>> can potentially just strip the binary, doesn't
>> matter really...
>>
>>
>> On Wed, Dec 5, 2012 at 3:52 PM,
>> [email protected]
>> <mailto:[email protected]> <
>> [email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Tom, the 'sudo strip -g libeo.so' on my
>> computer prevents me to see info
>> about this library in gdb, as explained
>> before. How can I compile Eo in
>> release mode?
>>
>> Gustavo, this could be very useful. We need
>> to check if it really can be
>> done and if it is easy for the user. Is the
>> eo_do_step supposed to
>> execute the functions too? How does it wait
>> for commands (your last
>> line), I mean, is it inside the eo_do_step
>> function?
>> Eo uses va_list to store the parameters and
>> we need to be careful with
>> that.
>>
>> On 12/05/2012 05:11 PM, Tom Hacohen wrote:
>>
>> Gustavo,
>>
>> Your suggestion is good (I already told
>> you that in the past, I think),
>>
>> but
>>
>> I believe it's unrelated to what we are
>> trying to achieve here. What I
>>
>> want
>>
>> is an easy way to step into an eo_do
>> function, just like we would have
>>
>> done
>>
>> with any other function.
>>
>> What I really want to see is just "run
>> until you exit the libeo.so
>>
>> binary
>>
>> and get back to a user function"...
>>
>>
>> On Wed, Dec 5, 2012 at 3:05 PM, Gustavo
>> Sverzut Barbieri <
>> [email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Let me jump in, proposing here what I
>> already proposed earlier at IRC
>> and in person during LinuxCon-EU:
>>
>> we should use the same debug helper
>> way as gcc does for itself.
>>
>> GCC is built on top of an union of
>> every possible AST node. So
>> functions, variables, loops... are
>> all into the same type/union,
>> making it dozen pages of gdb output
>> to get every possible field and
>> combination if you "p *node"
>>
>> To solve this they ship some
>> functions in their own code, that you
>> can use to debug its own code.
>> Similar to "p gcc_node_print(node)" (I
>> don't recall the exact name), and
>> another to navigate the tree.
>>
>> Then I propose we create a
>> "eo_do_step(obj, va_list ap)" that we
>> can:
>> "(gdb) p eo_do_step(obj, ap)" from
>> our debug session. It would
>> replicate the dispatch logic from
>> eo_do(), but before executing each
>> call it would print out the call and
>> parameters. We can use Eo
>> introspection to try to help user by
>> showing the function name,
>> description and parameter types.
>>
>> Suppose doing: eo_do(evas_obj,
>> evas_obj_position_set(10, 20),
>> evas_obj_size_set(300, 400));
>> you break point in eo_do and call:
>>
>> (gdb) p eo_do_step(obj, ap)
>> Operating on: obj=0xaabbcc00
>> (Evas_Object_Rectangle)
>> Function: evas_obj_position_set(int
>> x, int y) "Set the position of an
>> evas object."
>> calling: evas_obj_position_set(x=10,
>> y=20)
>> (eo_do_step) <--- waits for commands
>> such as continue, step...
>>
>>
>>
>>
>> On Wed, Dec 5, 2012 at 12:46 PM,
>> [email protected]
>> <mailto:[email protected]>
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi all,
>>
>> I don't need to reply, but to
>> thank you and give you respect, I
>> feel
>> that I must reply ;-) When I
>> strip Eo library, I cannot in gcc
>> step
>>
>> into
>>
>> at all, I mean, I can't reach the
>> final destination. It is like the
>> 'skip' feature of gdb. So for the
>> moment, I am stuck with that
>>
>> filename
>>
>> and need to find a solution.
>>
>> Second point, as I wrote before,
>> there is a bug in gdb when executing
>> python scripts (link below). It
>> will be fixed in gdb 7.6 that is
>> officially supposed to be
>> delivered in mid-february 2013
>> but as a gdb
>> maintainer said "In the past few
>> releases, we have typically been
>>
>> late
>>
>> by a few weeks.", I think we will
>> have to wait a little more.
>>
>> Hopefully, when I will have time,
>> I will insert this script into SVN
>>
>> and
>>
>> the installation will put it
>> automatically into the /opt/e17
>>
>> directory
>>
>> (or different). The question here
>> is if we have a common directory
>>
>> for
>>
>> all this nice weird stuff or if
>> it will be a new directory.
>>
>> JackDanielZ
>>
>> On 12/05/2012 04:24 PM, Tom
>> Hacohen wrote:
>>
>> Cool. And we already talked a
>> bit more on IRC about the
>> usage of the
>>
>> binary
>>
>> name vs. the source file
>> name, so I'm happy, no need
>> for your reply
>>
>> here.
>>
>> On 5 Dec 2012 05:16,
>> "[email protected]
>> <mailto:[email protected]>"
>> <
>>
>> [email protected]
>> <mailto:[email protected]>>
>>
>> wrote:
>>
>> Hey Tom,
>>
>> I saw your mail, I just
>> wanted to explain SeoZ
>> how to do now until
>>
>> I
>>
>> put
>>
>> it there automatically. I
>> will change the name to
>> eo_step.
>> I know this site, I don't
>> know yet which way to use
>> to configure
>>
>> gdb.
>>
>> For the moment, I create
>> manually a .gdbinit in my
>> home directory
>>
>> and
>>
>> there source the python
>> script.
>> Well, I can put the
>> script in src/utils/Eo
>> and then install it into
>> /opt/e17/share/eo/utils
>> or something like that.
>> But I think the
>>
>> user
>>
>> will have to configure
>> manually gdb, i.e add 'source
>> /opt/e17/.../eo_step.py'
>> into ~/.gdbinit.
>> Just for info, there is
>> some bug into gdb that
>> makes it crash with
>>
>> the
>>
>> script in a specific
>> scenario. I opened a ticket
>>
>> <http://sourceware.org/bugzilla/show_bug.cgi?id=14916>
>> there and
>>
>> hope
>>
>> it
>>
>> will help.
>>
>> Daniel
>>
>>
>> On 12/05/2012 01:29 AM,
>> Tom Hacohen wrote:
>>
>> Daniel,
>>
>> It should be
>> installed (as I've
>> said before) see
>>
>> http://sourceware.org/gdb/onlinedocs/gdb/Python.html
>> for more
>>
>> info.
>>
>> Then it'll be just a
>> matter of loading the
>> script and using it (or
>>
>> possibly
>>
>> it'll get loaded
>> automatically). Also,
>> as I said, I think
>> eo_jump
>>
>> is a
>>
>> terrible name and it
>> should be changed to
>> eo_step.
>>
>> Actually, reading
>> back the thread, you
>> didn't comment on any
>> of my
>>
>> messages.
>>
>> On Tue, Dec 4, 2012
>> at 12:13 PM,
>> [email protected]
>>
>> <mailto:[email protected]>
>> <
>> [email protected]
>>
>> <mailto:[email protected]>>
>> wrote:
>>
>> You open gdb and
>> you paste the
>> function (from
>> python to end)
>>
>> there.
>>
>> After, when you
>> encounter a eo_do
>> function, instead
>> of stepping
>>
>> into
>>
>> it,
>>
>> you call the
>> function (just
>> type eo_jump) and
>> it will do the job
>>
>> alone
>>
>> and reach the
>> function that you
>> wanted.
>>
>> On 12/04/2012
>> 10:54 AM, Daniel
>> Juyung Seo wrote:
>>
>> Awesome!!!!
>> I and
>> co-workers
>> have hard
>> time to debug
>> with eo.
>> This looks
>> very good but
>> how can I use it?
>>
>> Daniel Juyung
>> Seo (SeoZ)
>>
>> On Tue, Dec
>> 4, 2012 at
>> 5:15 PM,
>>
>> [email protected]
>>
>> <mailto:[email protected]>
>> <
>>
>> [email protected]
>>
>> <mailto:[email protected]>>
>> wrote:
>>
>> Hi all,
>>
>> I am sure
>> you faced
>> difficulties
>> to debug
>> your
>> program
>> due to
>>
>> changes
>>
>> with Eo.
>> It is
>> hard to
>> know
>> which
>> function
>> will be
>> called by
>>
>> eo_do
>>
>> or
>>
>> eo_do_super
>> because
>> of
>> inheritance.
>>
>> I have
>> written a
>> python
>> function
>> for gdb
>> that
>> helps a
>> lot. The
>>
>> command
>>
>> is
>> eo_jump,
>> no arguments.
>> You can
>> execute
>> it when
>> you reach
>> some
>>
>> eo_do/eo_do_super...
>> and
>>
>> it
>>
>> will
>>
>> jump over
>> Eo code.
>>
>> This is a
>> prototype
>> so sorry
>> for the
>> potential
>> bugs.
>>
>> For those
>> who will
>> look at
>> this
>> function,
>> you can
>> note some
>>
>> check
>>
>> that
>>
>> the
>> function
>> is None,
>> it is
>> because
>> Eo calls
>> for
>> memcpy. In
>>
>> this
>>
>> case,
>>
>> we want
>> it to not
>> stop on
>> this so
>> we have
>> to continue
>>
>> searching.
>>
>> Feel free
>> to
>> change,
>> propose,
>> hate this
>> script :)
>>
>> Daniel
>> (JackDanielZ)
>>
>> Function:
>> python
>> class
>>
>> Eo_jump(gdb.Command):
>>
>> def
>> __init__(self):
>>
>> gdb.Command.__init__(self,
>> "eo_jump",
>>
>> gdb.COMMAND_OBSCURE)
>>
>>
>> def
>> invoke
>> (self,
>> arg,
>> from_tty):
>> while True:
>>
>> gdb.execute("step")
>>
>> self.priv_filename
>> =
>>
>> gdb.selected_frame().find_sal().symtab.filename
>>
>> self.priv_function
>> =
>>
>> gdb.selected_frame().function()
>>
>> if
>>
>> (self.priv_filename
>> !=
>> "lib/eo/eo.c")
>> and
>>
>> (self.priv_function
>> != None):
>> break
>> if
>>
>> (self.priv_filename
>> ==
>> "lib/eo/eo.c"):
>>
>> gdb.execute("step")
>> if
>>
>> (self.priv_function
>> == None):
>>
>> gdb.execute("finish")
>> Eo_jump()
>> end
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> LogMeIn
>> Rescue:
>> Anywhere,
>> Anytime
>> Remote
>> support
>> for IT. Free
>>
>> Trial
>>
>> Remotely
>> access
>> PCs and
>> mobile
>> devices
>> and
>> provide
>> instant
>>
>> support
>>
>> Improve
>> your
>> efficiency,
>> and focus
>> on
>> delivering more
>> value-add
>>
>> services
>>
>> Discover
>> what IT
>> Professionals
>> Know.
>> Rescue
>> delivers
>>
>> http://p.sf.net/sfu/logmein_12329d2d
>>
>> _______________________________________________
>>
>> enlightenment-devel
>> mailing list
>>
>> [email protected]
>>
>> <mailto:[email protected]>
>>
>>
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>> ------------------------------------------------------------------------------
>>
>> LogMeIn
>> Rescue:
>> Anywhere,
>> Anytime
>> Remote
>> support for
>> IT. Free
>>
>> Trial
>>
>> Remotely
>> access PCs
>> and mobile
>> devices and
>> provide instant
>>
>> support
>>
>> Improve your
>> efficiency,
>> and focus on
>> delivering
>> more value-add
>>
>> services
>>
> ...
>
> [Message clipped]
>
>
>
>
> --
> Tom.
>
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
