Fwd: Speed up gdb loading

Tue Aug 3 07:14:25 BST 2021

Hi Ebuka,

please also post this response to the list so that it is consistent, the
thread is not broken, and others can follow the topics and information
gathered.

Regards
Ralf

-------- Weitergeleitete Nachricht --------
Betreff: 	Re: Speed up gdb loading
Datum: 	Tue, 3 Aug 2021 00:52:32 +0100
Von: 	Da Viper <yerimyah1 at gmail.com>
An: 	Ralf Habacker <ralf.habacker at freenet.de>

    Comparing this new file with printer.py, I see that one major
    difference is the usage of the brand new python 3.6 feature named
    f-string,
    also works with python3.
    Another difference is the int()/long() differences, for which a
    major version independent recipe is available:
    if sys.version_info[0] > 2:
        # int subsumes long
        long = int
    ...
    in code the use long() regardless of major version

the main reason i separated the python3 and 2 files is because of the
new  type format in python3  for example 
`address: str ` as it makes it easy to know what is going on 
however i could replace it with doc strings then merge the two files
together 

    you used the version from the mentioned kmymoney snapshots ?

no previously i was using the one in qtcreator,  once i change it works, 

    Debugging the IDE application may also be an option, but this needs
    some investigation, how the IDE implemented the debugging (does it
    call an external debugger or it that provided by the same process)
    and where the issue happens (inside the debugger or inside the IDE).
    It also requires debug symbols for the IDE application.

this problem, i was able to narrow it down to gdb-mi version since the
one in qtcreator is mi2  and the one in kmymoney is mi3 

On Mon, 2 Aug 2021, 22:34 Ralf Habacker, <ralf.habacker at freenet.de
<mailto:ralf.habacker at freenet.de>> wrote:

    Am 02.08.21 um 18:23 schrieb Da Viper:
>     Hello there I am currently do so,
>
>     But I have a problem with using python2,
>
>     It does not work for some classes in an ide but I cannot figure
>     out why,
>
>     I have updated the read me to add python 2
>
>     You have to import qtprinters_py2 to use python2
    Comparing this new file with printer.py, I see that one major
    difference is the usage of the brand new python 3.6 feature named
    f-string,

        def to_string(self) -> str:
            ucs = self.val['ucs']

            return f"{ucs} '{chr(ucs)}'"

    where the python 2 style

        def to_string(self):
            ucs = self.val['ucs']
            return "%d '%s'" % (ucs, chr(ucs))

    also works with python3.

    Another difference is the int()/long() differences, for which a
    major version independent recipe is available:

    if sys.version_info[0] > 2:
        # int subsumes long
        long = int

    ...

    in code the use long() regardless of major version

    See

https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libstdc%2B%2B-v3/python/libstdcxx/v6/printers.py#L46

<https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libstdc%2B%2B-v3/python/libstdcxx/v6/printers.py#L46>
    for further compatibility hints.

    https://python-future.org/compatible_idioms.html
    <https://python-future.org/compatible_idioms.html> also provides
    hints for how to write python 2 and 3 compatible code.

>     SCENARIO: 
>
>     For example we have a qfile 
>
>     `QFile file("/some/file/path");`
>
>     if I go to the command line gdb to print it, it works correctly,
    you used the version from the mentioned kmymoney snapshots ?
>
>     but when I try it within the IDE it crashes.
>     I think it has to do with the long type when reading the memory of
>     the QFile  in python2 but I am not sure. I tried using int() for
>     the address. But It is too large.
>
>     Is there a way to know what the actual problem is because it just
>     crashes without any traceback.

    Many applications on Windows uses the windows debug port, which can
    be inspected by dbgview (search on google), which needs to be
    started in front of the application in question.

    If that does not help, running the IDE from command line gdb or
    attaching gdb to the running IDE after it has been started should
    give you at least tracebacks in case an exception or segment
    violation occured.

    If that does not help adding print statements to your python code to
    see which line is working and which not, may give you some insights.
    Printing the value of variables can also help. Also installing a
    trace function may help, see for
    https://pymotw.com/2/sys/tracing.html
    <https://pymotw.com/2/sys/tracing.html>, which may give detailled
    output, but I haven't tried yet.

    Debugging the IDE application may also be an option, but this needs
    some investigation, how the IDE implemented the debugging (does it
    call an external debugger or it that provided by the same process)
    and where the issue happens (inside the debugger or inside the IDE).
    It also requires debug symbols for the IDE application.

    Regards

    Ralf

>
>     On Mon, 2 Aug 2021, 09:15 Ralf Habacker via Kde-finance-apps,
>     <kde-finance-apps at kde.org <mailto:kde-finance-apps at kde.org>> wrote:
>
>         Am 20.07.21 um 10:23 schrieb Ralf Habacker via Kde-finance-apps:
>         > Hi Ebuka,
>         >
>         > I remembered you mentioning the long loading time of gdb
>         when debug
>         > symbols are installed.
>         >
>         I recognized that the recent gdb version 10.2 speeds up symbol
>         loading on Windows, see
>
>         https://lists.gnu.org/archive/html/info-gnu/2021-04/msg00006.html
>         <https://lists.gnu.org/archive/html/info-gnu/2021-04/msg00006.html>
>         * Improved performance during startup through the use of threading
>         during symbol table loading (an optional feature in GDB 9, now
>         enabled by default in GDB 10).
>
>         You may verify this with a recent kmymoney snapshot from
>         https://kmymoney.org/snapshots.php#kmymoney5-aq6
>         <https://kmymoney.org/snapshots.php#kmymoney5-aq6>, which now
>         contains gdb 10.2.
>
>         If you want a standalone gdb package that is independent of
>         kmymoney and better suited for testing with your gdb printer
>         GSOC project, you can check
>         https://kmymoney.org/snapshots.php#gdb-snapshot
>         <https://kmymoney.org/snapshots.php#gdb-snapshot>.
>
>         Regards
>         Ralf
>