User forums > Embedded development

code::blocks::embedded

<< < (4/8) > >>

etg:
simply get the GDB source package and you develop until you get something usable. So if want to get output from command e.g. "info locals" you can split it into several libgdbXXX.dll calls create you own API and use it for your plugin. Solutions which parsing some output from other processes does not like for me and much more in case of debugger.

oBFusCATed:
So this is your independent lib based on the sources of gdb?

I don't like this parsing, too, but it is the only long term solution for using gdb.
The llvm's debugger will be lib based which is good :)

etg:
libgdbXXX.dll + libAPI.dll + C::B related work = debugger plugin
also usable as the libgdbXXX.dll + stub  = GDB.EXE

Upon target device selection for a project can in future use different variants of libgdbXXX.dll as ARM, MIPS, SUPERH etc.

I agree that in open world is quite hard to maintain such kind of code

etg:
I just want to ask how far is the time when your C::B turns into commercial edit ?

oBFusCATed:
What exactly do you ask?

1. If some company will buy C::B and thus C::B becomes a proprietary software?
2. If C::B will catch the commertial IDEs (like VStudio)?

1. never
2. it depends on the user's contrubution I think :), btw in some areas it is ages in front of VStudio, in some it is quite behind...

Navigation

[0] Message Index

[#] Next page

[*] Previous page