Extension modules in C++
 

Hi all,

as part of SUSE HackWeek8, David started work on a GUI extension using Qt4,
which is a C++ project. One of the early annoyances is that an extension
module must include the declarations from defs.h, and we currently use some C
identifiers which happen to be keywords in C++, namely:

- struct namespace
- struct namespace namespace (in struct symbol_table_data)
- char *typename (in struct gnu_request)

Can I rename them? But you said earlier that the existing API must never
change... Any other suggestions to make this include file parseable by a C++
compiler?

TIA,
Petr Tesarik
SUSE Linux

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Extension modules in C++
 

On Thu, Jul 26, 2012 at 10:57 AM, Petr Tesarik <ptesarik@suse.cz> wrote:
> Hi all,
>
> as part of SUSE HackWeek8, David started work on a GUI extension using Qt4,
> which is a C++ project. One of the early annoyances is that an extension
> module must include the declarations from defs.h, and we currently use some C
> identifiers which happen to be keywords in C++, namely:
>
> - struct namespace
> - struct namespace namespace (in struct symbol_table_data)
> - char *typename (in struct gnu_request)
>
> Can I rename them? But you said earlier that the existing API must never
> change... Any other suggestions to make this include file parseable by a C++
> compiler?

One hack you could consider would be to do something like this:

extern "C" {
#define namespace ns
#include "defs.h"
#undef namespace
}

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Extension modules in C++
 

Hello Petr,

On Thu, 26 Jul 2012 11:57:05 +0200
Petr Tesarik <ptesarik@suse.cz> wrote:

> Hi all,
>
> as part of SUSE HackWeek8, David started work on a GUI extension
> using Qt4, which is a C++ project.

Not sure if this is useful for you, but:

Several years ago a student at IBM implemented a GUI for lcrash in Qt.
The main feature was the possibility to graphally browse kernel data
structures. The name of the tool was qlcrash. The lkcd project is dead,
but you still still can download the code from:

http://http://sourceforge.net/projects/lkcd/

The code is located under the qlcrash directory. E.g.:

http://lkcd.svn.sourceforge.net/viewvc/lkcd/branches/lkcd-6_1_0-large/lkcdutils/qlcrash/

Michael

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Extension modules in C++
 

Dne Čt 26. července 2012 14:02:56 Adrien Kunysz napsal(a):
> On Thu, Jul 26, 2012 at 10:57 AM, Petr Tesarik <ptesarik@suse.cz> wrote:
> > Hi all,
> >
> > as part of SUSE HackWeek8, David started work on a GUI extension using
> > Qt4, which is a C++ project. One of the early annoyances is that an
> > extension module must include the declarations from defs.h, and we
> > currently use some C identifiers which happen to be keywords in C++,
> > namely:
> >
> > - struct namespace
> > - struct namespace namespace (in struct symbol_table_data)
> > - char *typename (in struct gnu_request)
> >
> > Can I rename them? But you said earlier that the existing API must never
> > change... Any other suggestions to make this include file parseable by a
> > C++ compiler?
>
> One hack you could consider would be to do something like this:
>
> extern "C" {
> #define namespace ns
> #include "defs.h"
> #undef namespace
> }

Yes! That works, although I'm not entirely sure it can't do any harm. After
all, it's what you called it - a hack. ;-)

I wonder whether Dave (Anderson) can suggest a cleaner solution (or make an
official statement that he doesn't care about C++ compatibility).

Petr Tesarik
SUSE Linux

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Extension modules in C++
 

On July 26, 2012 11:57:05 AM Petr Tesarik wrote:

> Hi all,

>

> as part of SUSE HackWeek8, David started work on a GUI extension using Qt4,*

> which is a C++ project.

*

Hi all,

*

I have a working prototype (still in Alpha) of Python-Qt based GUI that works remotely using the following approach:

*

- at server side, you load PyKdump and do 'epython server'

- at your local PC, you run 'python guimain.py'

*

Communication is done using TCP and exchanging records with headers containing data length.

*

At this moment the project is in early stages (proof of concept) but already usable. Because PyQT is portable, the same sources work both on Linux and Windows clients.

*

I think that building GUI directly on top of crash is not the best approach - it is easier to add a small extension to crash and then communicate with it (if done locally, we could use shared memory or AF_UNIX sockets).

*

A similar approach (driving GDB externally instead of linking with it) is already used in several GUI debuggers, e.g. 'ddd'.

*

Regards,

Alex

*

--

------------------------------------------------------------------

Alexandre Sidorenko email: asid@hp.com

WTEC Linux Hewlett-Packard (Canada)

------------------------------------------------------------------

*
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Extension modules in C++
 

Hello Alex,

On Wed, 01 Aug 2012 18:06:51 -0400
Alex Sidorenko <alexandre.sidorenko@hp.com> wrote:

> On July 26, 2012 11:57:05 AM Petr Tesarik wrote:
> > Hi all,
> >
> > as part of SUSE HackWeek8, David started work on a GUI extension
> > using Qt4, which is a C++ project.
>
> Hi all,
>
> I have a working prototype (still in Alpha) of Python-Qt based GUI
> that works remotely using the following approach:
>
> - at server side, you load PyKdump and do 'epython server'
> - at your local PC, you run 'python guimain.py'
>
> Communication is done using TCP and exchanging records with headers
> containing data length.
>
> At this moment the project is in early stages (proof of concept) but
> already usable. Because PyQT is portable, the same sources work both
> on Linux and Windows clients.
>
> I think that building GUI directly on top of crash is not the best
> approach - it is easier to add a small extension to crash and then
> communicate with it (if done locally, we could use shared memory or
> AF_UNIX sockets).
>
> A similar approach (driving GDB externally instead of linking with
> it) is already used in several GUI debuggers, e.g. 'ddd'.

Again just for your information:

qlcrash used an similar aproach. The communication layer was
pluggable. Besides of a local plugin there was a remote plugin that
talked to an lcrash daemon via TCPIP. We could even run
qlcrash on windows clients and debug remote s390 dumps.

See:

local: lkcdutils/qlcrash/plugins/localplugin.cpp
remote: lkcdutils/qlcrash/plugins/tcpplugin.cpp
lcrash daemon: lkcdutils/lcrashd

Perhaps some of the code could be reused for your project.

Michael

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Extension modules in C++
 

On August 2, 2012 11:22:26 AM Michael Holzheu wrote:

> Again just for your information:

>

> qlcrash used an similar aproach. The communication layer was

> pluggable. Besides of a local plugin there was a remote plugin that

> talked to an lcrash daemon via TCPIP. We could even run

> qlcrash on windows clients and debug remote s390 dumps.

>

> See:

>

> local: lkcdutils/qlcrash/plugins/localplugin.cpp

> remote: lkcdutils/qlcrash/plugins/tcpplugin.cpp

> lcrash daemon: lkcdutils/lcrashd

>

> Perhaps some of the code could be reused for your project.

*

Hello Michael,

*

thank you - I will look at that.

*

Regards,

Alex

*

--

------------------------------------------------------------------

Alexandre Sidorenko email: asid@hp.com

WTEC Linux Hewlett-Packard (Canada)

------------------------------------------------------------------

*
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Extension modules in C++
 

----- Original Message -----
> Dne Čt 26. července 2012 14:02:56 Adrien Kunysz napsal(a):
> > On Thu, Jul 26, 2012 at 10:57 AM, Petr Tesarik <ptesarik@suse.cz>
> > wrote:
> > > Hi all,
> > >
> > > as part of SUSE HackWeek8, David started work on a GUI extension using
> > > Qt4, which is a C++ project. One of the early annoyances is that an
> > > extension module must include the declarations from defs.h, and we
> > > currently use some C identifiers which happen to be keywords in C++,
> > > namely:
> > >
> > > - struct namespace
> > > - struct namespace namespace (in struct symbol_table_data)
> > > - char *typename (in struct gnu_request)

And it seems that "namespace" is used for other purposes in files
like ppc.c and ppc64.c...

The "typename" is changeable, in fact I don't think it's really used
except for debugging purposes, although it would break the capability
of using other (earlier) versions of gdb. I would say that most people
use the most recent gdb version, but it always seems that there's somebody
still doing things differently. But that could be dealt with by #ifdef'ing
the structure member declaration in defs.h based upon the relevant GDB_X_X
setting, because gdb/symtab.c wouldn't see it. Kind of ugly, though...

> > >
> > > Can I rename them? But you said earlier that the existing API must never
> > > change... Any other suggestions to make this include file parseable by a
> > > C++ compiler?
> >
> > One hack you could consider would be to do something like this:
> >
> > extern "C" {
> > #define namespace ns
> > #include "defs.h"
> > #undef namespace
> > }
>
> Yes! That works, although I'm not entirely sure it can't do any harm.
> After all, it's what you called it - a hack. ;-)

But it can't harm the crash utility, right? ;-)

> I wonder whether Dave (Anderson) can suggest a cleaner solution (or make an
> official statement that he doesn't care about C++ compatibility).
>
> Petr Tesarik
> SUSE Linux

To be honest, I really don't care about C++ compatibility -- with the realization
that I'm already offending somebody. If Adrien's suggestion works, I suppose I'd
prefer to keep things as they are. But if you really want to submit a patch,
I'll entertain it as always...

Dave




--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Extension modules in C++
 

----- Original Message -----
>
>
> ----- Original Message -----
> > Dne Čt 26. července 2012 14:02:56 Adrien Kunysz napsal(a):
> > > On Thu, Jul 26, 2012 at 10:57 AM, Petr Tesarik <ptesarik@suse.cz>
> > > wrote:
> > > > Hi all,
> > > >
> > > > as part of SUSE HackWeek8, David started work on a GUI extension using
> > > > Qt4, which is a C++ project. One of the early annoyances is that an
> > > > extension module must include the declarations from defs.h, and we
> > > > currently use some C identifiers which happen to be keywords in C++,
> > > > namely:
> > > >
> > > > - struct namespace
> > > > - struct namespace namespace (in struct symbol_table_data)
> > > > - char *typename (in struct gnu_request)
>
> And it seems that "namespace" is used for other purposes in files
> like ppc.c and ppc64.c...

Of course that's irrelevant to the discussion...

> The "typename" is changeable, in fact I don't think it's really used
> except for debugging purposes, although it would break the capability
> of using other (earlier) versions of gdb. I would say that most people
> use the most recent gdb version, but it always seems that there's somebody
> still doing things differently. But that could be dealt with by #ifdef'ing
> the structure member declaration in defs.h based upon the relevant GDB_X_X
> setting, because gdb/symtab.c wouldn't see it. Kind of ugly,
> though...
>
> > > >
> > > > Can I rename them? But you said earlier that the existing API must never
> > > > change... Any other suggestions to make this include file parseable by a
> > > > C++ compiler?
> > >
> > > One hack you could consider would be to do something like this:
> > >
> > > extern "C" {
> > > #define namespace ns
> > > #include "defs.h"
> > > #undef namespace
> > > }
> >
> > Yes! That works, although I'm not entirely sure it can't do any harm.
> > After all, it's what you called it - a hack. ;-)
>
> But it can't harm the crash utility, right? ;-)
>
> > I wonder whether Dave (Anderson) can suggest a cleaner solution (or make an
> > official statement that he doesn't care about C++ compatibility).
> >
> > Petr Tesarik
> > SUSE Linux
>
> To be honest, I really don't care about C++ compatibility -- with the realization
> that I'm already offending somebody. If Adrien's suggestion works, I suppose I'd
> prefer to keep things as they are. But if you really want to submit a patch,
> I'll entertain it as always...
>
> Dave

Petr,

On second thought, I'll just take of this in crash-6.0.9. It's not
that big a deal...

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Extension modules in C++
 

On 08/01/2012 04:06 PM, Alex Sidorenko wrote:
> On July 26, 2012 11:57:05 AM Petr Tesarik wrote:
>> Hi all,
>>
>> as part of SUSE HackWeek8, David started work on a GUI extension using Qt4,
>> which is a C++ project.
>
> Hi all,
>
> I have a working prototype (still in Alpha) of Python-Qt based GUI that works
> remotely using the following approach:
>
> - at server side, you load PyKdump and do 'epython server'
> - at your local PC, you run 'python guimain.py'
>
> Communication is done using TCP and exchanging records with headers containing
> data length.
>
> At this moment the project is in early stages (proof of concept) but already
> usable. Because PyQT is portable, the same sources work both on Linux and
> Windows clients.
>
> I think that building GUI directly on top of crash is not the best approach -
> it is easier to add a small extension to crash and then communicate with it
> (if done locally, we could use shared memory or AF_UNIX sockets).
>
> A similar approach (driving GDB externally instead of linking with it) is
> already used in several GUI debuggers, e.g. 'ddd'.

Hi Alex,

It's my Hack Week work that Petr was talking about, I'm interested in
the idea of merging anything useful into your project or re-basing my
thoughts on your interface, do you have a site or list I can contribute at?

--
David.

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility