FB debugger : 2.96 32/64 BIT ..... (2020/02/17)

User projects written in or related to FreeBASIC.
SARG
Posts: 1160
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby SARG » Dec 18, 2014 21:55

AGS wrote:Looking at the code it's the window text of hcurline that is causing the problem (code is in sub dsp_change, line
3226 and further).

Code: Select all

   sendmessage(dbgrichedit,EM_GETSELTEXT,0,Cast(LPARAM,@l))   
   setWindowText(hcurline,"Current line ["+Str(curlig)+"]:"+LTrim(l,Any " "+Chr(9)))

The variable l has type zstring * 300. That could be causing the problems. If variable l would be type wstring * 300 then perhaps the text would show up correctly. setWindowText does not display unicode content.

I did a few tries without success. The issue comes from sendmessage(dbgrichedit,EM_GETSELTEXT,0,Cast(LPARAM,@l)) .
The return value is not an UTF8 string. So no easy way to fix it. Anyway thanks for your testing.

I'm currently working on a new version using FLTK. That problem will not exist any more as every loaded file text is translated in UTF8.
In case somebody has requests about the GUI don't hesitate to ask.
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby AGS » Jan 09, 2015 8:58

When opening an executable you always get the following message

Code: Select all

Error : objdump.exe must be in the directory of fbdebugger
Only usefull in case of option -gcc, in case -gas option don't take it in account
Objdump is also needed if case -gcc and -gas mixed code


But you also get that message after a call to DyLibLoad

Code: Select all

lib_handle = dylibload("some_library")


You get as many messages as there are calls to dylibload in your program. In some cases that might be useful (maybe if you have the source code of the dynamic library). But most of the time I use dylibload to load libraries for which I have downloaded binaries but not the source code.

I am unsure why you'd want to use objdump on a dynamic library of which you don't have the source code. Which accounts for the majority of use cases of dylibload (I think?). The loaded library cannot be debugged on a line-by-line base (as the needed info isn't available). And even if that info were available then the user would be looking at C code. I don't think you can use fbdebugger to debug C source code.

As a solution to the objdump - message - 'problem' I am thinking along the lines of an option.

If the dynamic library was written in freebasic then debugging the code contained within the library would be very handy. If on the other hand the dynamic library was written in C then the entire dynamic library should be considered opaque. The only info on it's content would be the declarations as found in the fb code.

The only thing you would be able to perform on a function from a dynamic library would be to use step over but not step in. Dynamically loaded library could be considered opaque (no debug info available) by default. If the user knows the dynamically loaded library contains debugging info and source code is available and written in FreeBASIC then objdump could do it's job.

By the way: how is that fltk version coming along? Do you have something to 'show'? A demo perhaps? Could you use some help?
SARG
Posts: 1160
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby SARG » Jan 10, 2015 0:23

AGS wrote:When opening an executable you always get the following message

Code: Select all

Error : objdump.exe must be in the directory of fbdebugger
Only usefull in case of option -gcc, in case -gas option don't take it in account
Objdump is also needed if case -gcc and -gas mixed code


But you also get that message after a call to DyLibLoad

Code: Select all

lib_handle = dylibload("some_library")


You get as many messages as there are calls to dylibload in your program. In some cases that might be useful (maybe if you have the source code of the dynamic library). But most of the time I use dylibload to load libraries for which I have downloaded binaries but not the source code.

I am unsure why you'd want to use objdump on a dynamic library of which you don't have the source code. Which accounts for the majority of use cases of dylibload (I think?). The loaded library cannot be debugged on a line-by-line base (as the needed info isn't available). And even if that info were available then the user would be looking at C code. I don't think you can use fbdebugger to debug C source code.

As a solution to the objdump - message - 'problem' I am thinking along the lines of an option.

If the dynamic library was written in freebasic then debugging the code contained within the library would be very handy. If on the other hand the dynamic library was written in C then the entire dynamic library should be considered opaque. The only info on it's content would be the declarations as found in the fb code.

The only thing you would be able to perform on a function from a dynamic library would be to use step over but not step in. Dynamically loaded library could be considered opaque (no debug info available) by default. If the user knows the dynamically loaded library contains debugging info and source code is available and written in FreeBASIC then objdump could do it's job.

I know everything you wrote.
Objdump is needed if -gcc compil option is used for the main program, a dll or a static lib. Fbdebugger calls objdump to retrieve the debugging data (dwarf).
The problem is that it's not possible to know if a static lib (compiled with fbc and gcc option) is included without extracting the data........ And even without -gcc, there is also the debugging data brings by the GCC tools, fbdebugger finds debugging sections and the subroutine is unnecessarily called. I hope that's almost clear ;-)

One solution would be to remove the message. And if one uses -gcc, objdump MUST be put in the folder of fbdebugger to get a correct debugging.

AGS wrote:By the way: how is that fltk version coming along?
I really don't know, honnestly I dont spend a lot of time on this project (playing FPS takes me more time). Currently I'm trying to reuse the maximum of code (not sure that's a good way). I have to replace the Windows's API (except system calls) by the corresponding fltk functions. Not so simple.... After I have to test the version under Windows. After I have to implement the linux version. After I have to adapt the code for 64bit.

AGS wrote:Do you have something to 'show'?A demo perhaps?

I could upload the current code but for now this would not be very usefull. Anyway I'll do it when a version will be enough interesting.

AGS wrote: Could you use some help?

Thank you for the offer.
FLTK lib, D.j.Peters gives me almost what I need.
Linux, I'm a newbie under Linux so some help for testing will be welcome.
Testing seems the best help but why not also ideas about UI and even coding :-)
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby AGS » Jan 15, 2015 11:33

As far as debugging on Linux is concerned one look at existing Linux (gui-enabled) debuggers is enough. All of those are written as GDB - front ends. And most of those use the GDB-mi interface. GDB is also available on windows. GDB supports most of what fbdebugger supports (eg setting breakpoints, getting the value of variables etc...). Writing a GDB front end (using gdb-mi) would be one way to create a cross - platform FreeBASIC debugger. Link to gdb-MI interface description https://sourceware.org/gdb/current/onli ... GDB_002fMI

I found a small 'bug' in fbdebugger version 2.81. (my source code compiled with -gen gas) ctrl - clicking on a variable can get you the message

Code: Select all

VARIABLE is not a running variable


even when VARIABLE is known to fbdebugger and is a running variable. The variable shows up in the right pane as a global variable which 'proves' that it's a running variable (otherwise it would not show up as a proc/var in the right pane).

The problem seems to be that the variable is used like so

Code: Select all

using namespace
VARIABLE = ....


and VARIABLE is declared in namespace (it's a global variable). VARIABLE might not be known as such but namespace.VARIABLE is known. As mentioned the variable does show up in the right pane. Searching the list of global variables might solve the problem. Something like (pseudo code)

Code: Select all

if variable is not a known running variable then
  search list of global variables for variable
  if found then variable is a running variable
end if


As far as porting fbdebugger code to fltk goes: reuse of static components (eg 'look' of the debugger) seems like a good place to start. As far as the dynamic part of the gui goes: a lot of messages sent using SendMessage actually set some property of a widget. In fltk that can be done directly using the appropriate functions.

Message handling of buttons is easily replaced with button - specific callbacks. Actions performed when buttons are clicked can be copy-pasted to the button handler (handler code will need editing of course). Menu handling can largely be copied as is because fltk supports easy creation of menus. Again: actions associated when choosing a menu can be copy-pasted to the appropriate handler (some editing needed).

On the whole I think the porting issue isn't all that bad since gui creation in fbdebugger is handled by functions that somewhat 'wrap' the win32 api. Those wrapper functions can just as easily wrap the fltk api.

[aside]
Personally I wonder whether it would not be a better idea to port fbdebugger to gtk+. It has a C interface so the bindings are easier to create/recreate/update. Using a wrapper around fltk you depend upon someone else to keep bindings to a C++ library up-to-date and working (which isn't all that easy).
[/aside]

How far are you with porting fbdebugger to fltk? Could I 'jump in' and finish the job? I'd prefer to start with a 'vanilla' version of fbdebugger (win32 api) though. My aim would be to make the gui work on both linux and windows. And to make sure the debugger part works on windows. The decision on how to achieve cross - platform debugging capabilities (either using gdb or otherwise) would not be an issue (the linux version will just consist of a gui without debugging capabilities). As far as gui toolkits go I'm fine with using either gtk+ or fltk.
SARG
Posts: 1160
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby SARG » Jan 16, 2015 0:14

Hi AGS,

Wouah big post :-) Too late to write a complete answer.

I'll fix (I hope) the bug with variables in namespace this weekend.

GTK+ why not (fltk is relatively simple but some points are not so good). And you are right (I have also thought about this point) FLTK is very dependent of D.J.Peters...
I have to look at some GTK examples.

You could see how far is the new fbdebugger. Unzip all the files and just compile fbdebug2.bas (-s console to see prints). Objdump must be in the same folder. It's used to retrieve data debugging. Even if there is stabs I don't extract this data from the memory. Dwarf data to hard to understand.
You can launch an exe and use the step by step button (first left one).
Source codes are displayed and Tabs are still under working (as a lot of things). Procs tab is nearly ok.
http://users.freebasic-portal.de/sarg/fbdebug2.zip

My goal is to make fbdebugger with the same features under Linux than under Windows, 32bit as well 64bit.
What a challenge ;-). I have read a lot of docs/codes and I have already some subroutines for these new OS.

If you accept that we work together (I don't yet know how) , send me an email address to facilitate the exchanges. Mine is in the fbdebugger about. Welcome in board.
SARG
Posts: 1160
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby SARG » Jan 18, 2015 23:08

Hi all,

@TJF
Reminder: thank you for your offer. "Only fools never change their minds" is what I ALWAYS say ;-)
I took a quick glance to the examples of GTK. Some questions/issues :
- Glade, Tobac, GTK for what use ?
- I tried to compile an example but I got errors : few libs missing. No time to search/fix that.

I do not want that fbdebugger's users have to do complex operations for compiling (using fltk is just adding a dll or so file).
But as the syntax seem equivalent why not trying to adapt fbdebg under GTK.
Please, provide me websites where I can find docs (the basis instructions, easily readable) and a small but complete example.

@AGS
I prefer to keep my way : use objdump to extract debugging data and the rest done in fbdebugger.
I have to clean a bit the code and I'll upload a version removing the message about objdump.

To fix the bug about "variables not found because they are in a namespace". Try this mod inside the proc named 'var_tip'.

Code: Select all

    If idx=-1 Then
        idx=var_search(1,vname(),vnb,varray) 'inside main ?
'========================================================================
'===========  mod to fix bug reported by AGS :  variable in namespace not found ===       
'========================================================================
        If idx=-1 Then '18/01/2015
        'namespace ?
           If vnb>1 Then
              vname(1)+="."+vname(2)
              vnb-=1
              For i As Long =2 To vnb
                 vname(i)=vname(i+1)
              Next
              idx=var_search(1,vname(),vnb,varray)
           EndIf
           If idx=-1 Then   fb_message("Selection variable error",""""+Left(text,Len(text)-1)+""" is not a running variable"):Exit Sub
        EndIf
    End If
'============== end of mod ==============   
    tv=vrr(idx).tv 
    If ope=PROCVAR Then
TJF
Posts: 3604
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby TJF » Jan 19, 2015 10:21

SARG wrote:@TJF
Reminder: thank you for your offer. "Only fools never change their minds" is what I ALWAYS say ;-)

Does 'I ALWAYS say' mean that you never change your mind about those people ?-)

SARG wrote:Some questions/issues :
- Glade, Tobac, GTK for what use ?

  • Glade = grafical GUI designer, outputs a file that describes a GUI (suffix .ui).
  • GladeToBac = FB code sketcher, reads .ui file and creates FB code. In a first run it creates a framework of .bas files to run the GUI, in further runs it updates the FB callbacks (one file per callback) defined in the GUI file.
  • GTK+ = toolkit (dynamic libraries) used by your app (and Glade and GladeToBac).

SARG wrote:- I tried to compile an example but I got errors : few libs missing. No time to search/fix that.


SARG wrote:Please, provide me websites where I can find docs (the basis instructions, easily readable) and a small but complete example.

  • Docs
    • Glib: A general-purpose utility library, not specific to graphical user interfaces. GLib provides many useful data types, macros, type conversions, string utilities, file utilities, a main loop abstraction, and so on.
    • GObject: A library that provides a type system, a collection of fundamental types including an object type, a signal system.
    • GIO: A modern, easy-to-use VFS API including abstractions for files, drives, volumes, stream IO, as well as network programming and DBus communication.
    • cairo: Cairo is a 2D graphics library with support for multiple output devices.
    • Pango Pango is a library for internationalized text handling. It centers around the PangoLayout object, representing a paragraph of text. Pango provides the engine for GtkTextView, GtkLabel, GtkEntry, and other widgets that display text.
    • ATK ATK is the Accessibility Toolkit. It provides a set of generic interfaces allowing accessibility technologies to interact with a graphical user interface. For example, a screen reader uses ATK to discover the text in an interface and read it to blind users. GTK+ widgets have built-in support for accessibility using the ATK framework.
    • GdkPixbuf This is a small library which allows you to create GdkPixbuf ("pixel buffer") objects from image data or image files. Use a GdkPixbuf in combination with GtkImage to display images.
    • GDK GDK is the abstraction layer that allows GTK+ to support multiple windowing systems. GDK provides window system facilities on X11, Windows, and OS X.
    • GTK+ The GTK+ library itself contains widgets, that is, GUI components such as GtkButton or GtkTextView.
  • Examples

SARG wrote:I do not want that fbdebugger's users have to do complex operations for compiling (using fltk is just adding a dll or so file).

I use CMake, it can generate NSIS installers.

SARG wrote:But as the syntax seem equivalent why not trying to adapt fbdebg under GTK.

This seems to be no good idea. You'll soon come to a point where you have to select either fltk or GTK+. Ie.

  • fltk doesn't support horizontal scrolling of a tab window,
  • it doesn't have full UTF-8 support yet,
  • flexible widget sizing is missing (works with fixed positions / sizes only),
  • working with a GUI designer is much more convenient and faster than compiling and testing source code,
  • ...
It doesn't make sence to learn and use GTK+ at the fltk level.
SARG
Posts: 1160
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby SARG » Jan 19, 2015 13:51

Hi,

I forgot to put in my previous post a change to be done inside the function cutup_names. Otherwise the variable will never be found.....

Code: Select all

   nm2=Mid(strg2,d,p)
   'Return "NS : "+nm+"."+nm2
   Return nm+"."+nm2 '17/01/2015
End Function


@TJF
"Only fools never change their minds" is what I ALWAYS say ;-)
It's a joke : the sentence could be applied to myself as I always say that, I 'm also a fool.

TJF wrote:
SARG wrote:But as the syntax seem equivalent why not trying to adapt fbdebg under GTK.

This seems to be no good idea. You'll soon come to a point where you have to select either fltk or GTK+.

I wanted to say that the changes between Fltk and GTK+ seems less important than between Windows's APIs and FLTK. So after porting under FLTK the porting under GTK+ will be easier. That's doing the job twice but someone else than me could do it.
In the meantime I can go forward on Linux and 64bit.

Thank you for all the information. I hope have a bit of time to study it. :-)
TJF
Posts: 3604
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby TJF » Jan 19, 2015 14:37

SARG wrote:My goal is to make fbdebugger with the same features under Linux than under Windows, 32bit as well 64bit.
What a challenge ;-)

SARG wrote:In the meantime I can go forward on Linux and 64bit.

Thank you for all the information. I hope have a bit of time to study it. :-)

I offer my help because I want to learn about debugging, what I never used before. My idea is

  • SARG goes forward on Linux and 64bit
  • TJF makes the GUI (based on images of the existing GUI)
  • AGS does testing and reports bugs (and surely will have ideas for new features)
This would be a strange team, we could all learn from each other. It's up to you, just make your mind.
St_W
Posts: 1508
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby St_W » Jan 19, 2015 15:33

It's nice to see that fbDebugger is going to get some new UI. The reason why I think that's important is that UI and other code should be separated. Currently afaik everything is one big module containing everything wildly mixed. Therefore I agree with SARG that the question which UI toolkit to use is not that important, as it gets easier to implement other UIs as soon as UI code is properly separated from other code.
SARG
Posts: 1160
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby SARG » Jan 19, 2015 16:00

TJF wrote:
SARG wrote:My goal is to make fbdebugger with the same features under Linux than under Windows, 32bit as well 64bit.
What a challenge ;-)

SARG wrote:In the meantime I can go forward on Linux and 64bit.

Thank you for all the information. I hope have a bit of time to study it. :-)

I offer my help because I want to learn about debugging, what I never used before.

No problem I'm ready to explain how that is working.

TJF wrote: My idea is

  • SARG goes forward on Linux and 64bit
  • TJF makes the GUI (based on images of the existing GUI)
  • AGS does testing and reports bugs (and surely will have ideas for new features)

After so many years doing things alone that's obviously interesting. Waiting to know what AGS is thinking.

Some remarks:
    - The existing GUI should evolve. For example I'm adding a tab for memory instead an area in the main window. And there are a lot of things under the hood.
    - Installation should (must) stay easy for beginners.
    - No tutorial is currently an important lack. It would allow to show to beginners the principles and what kind of help a debugger brings. It would be good to have it integrated into the debugger.
    - Documentation is also important but not funny to make.
TJF wrote:This would be a strange team, we could all learn from each other. It's up to you, just make your mind.

Not so strange : our pseudos are all with few letters in upper case. Maybe the 3 fantastic devs. Sorry dkl no upper case and counting_pine too long...... ;-)

By the way, every url 'developer.gnome.org' fails.
SARG
Posts: 1160
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby SARG » Jan 19, 2015 16:17

@St_W
Currently I'm splitting the monolithic code into several modules. Now I have trouble to find where things are done :-( Happily with fbedit the search function could be used in all opened modules.

However don't imagine it will be easy to reuse code in an editor to add debugging functionnalities ;-)
TJF
Posts: 3604
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby TJF » Jan 19, 2015 18:03

SARG wrote:By the way, every url 'developer.gnome.org' fails.

All work fine here. Does the first one Docs work? It contains most of the other links.

SARG wrote:No problem I'm ready to explain how that is working.

I don't want to learn theory. Learning by building the GUI and testing is enough. (I may have some detailed questions, later on.)

SARG wrote:- The existing GUI should evolve. For example I'm adding a tab for memory instead an area in the main window. And there are a lot of things under the hood.

I do not want to re-invent the wheel, just make the current GUI cross-platform. As St_W mentioned, it's important to separate GUI code from the functional code. This happens by default, since the GUI is described in external file(s). (The FB code only contains GUI interaction like set_label or get_entry.)

SARG wrote:- Installation should (must) stay easy for beginners.

We could organize the build and install process by Cmake. CPack can generate archives or installers for different target platforms. Splitting the monolithic code in to modules helps to shorten the build process. We could use the GResource framework to pack all resources (*.ui files, images, ...) in to one compressed file. We also could append this file to the executable to ship just one file (with Data2App), if you like.

SARG wrote:- Documentation is also important but not funny to make.

I use fb-doc and Doxygen to auto-generate documentation from the FB source code.

SARG wrote:- No tutorial is currently an important lack. It would allow to show to beginners the principles and what kind of help a debugger brings. It would be good to have it integrated into the debugger.

Doxygen can also integrate tutorial / description pages in to the source documentation, written in easy writable / readable markup language. Ie. check out the libpruio documentation.

My remark:
  • I'd like to use git as version control system and create a central repository (ie. on GitHub or SourceForge).
SARG wrote:Waiting to know what AGS is thinking.

Yep, me too!
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: FB debugger : 2.81 Beta 01 (november 30th, 2014)

Postby AGS » Jan 19, 2015 20:44

I think a port using GTK+ written by TJF is a good idea. With the restriction that it has to be written in 'plain' GTK+. No glade, just plain function calls to GTK+ functions (eg gtk_toolbar_new() to create the toolbar, repeated calls to gtk_tool_button_new)' to create individual tool buttons etc...).
SARG has to be able to maintain the code after TJF has finished creating the port. And if SARG wants 'low level' gtk then low level gtk is what he should get.

It would be more practical if, during porting of the gui, there are no updates of gui related code. Or even no update of fbdebugger. Otherwise TJF would be faced with having to update his code while he is porting it.

My role in all of this seems to have gone from my initial plan to port the gui to testing. That's fine by me. If TJF can live with writing 'low-level' GTK and SARG is willing to let TJF port the gui to GTK then I can sit back, relax, and let the code come to me :)

Return to “Projects”

Who is online

Users browsing this forum: No registered users and 12 guests