Now this looks cool (except for the "stopped at file..." thing)! :)

I don't quite understand your question about /opt/e17. If you just want to
install it you just add it to Makefile.am like you would do any other data
file (look at efl/data if you don't know how for some reason). The problem
is that you probably don't want to install it to the same prefix as the
efl, but actually to the gdb python dir, and you need to find a way to
probe that. If that can't be probed, just install to the prefix, I guess
it's "good enough".

--
Tom.


On Tue, Dec 11, 2012 at 6:01 AM, [email protected] <
[email protected]> wrote:

>  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] <
> [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] <
>> [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] <
>>>> [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] <
>>>>>> [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]> 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]
>>>>>>>>> <[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]" <
>>>>>>>>>>>
>>>>>>>>>>  [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] <
>>>>>>>>>>>>> [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] <
>>>>>>>>>>>>>>> [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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  ...
>
> [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

Reply via email to