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

User projects written in or related to FreeBASIC.
jmg
Posts: 89
Joined: Mar 11, 2009 3:42

Re: FB debugger : 2.59 (15 APR 2012)

Postby jmg » May 17, 2012 21:18

MOD wrote: If using Scintilla is too much work, what about setting FB-keywords bold.


Some compromise sounds a good idea, and I would modify this slightly, to be FB keywords that are active-code.
ie comments, and source that is 'off' because it is inside conditionals, should not be highlighted.

It does not need to be as fully 'Editor fancy', but knowing at a glance which lines you can set a break point on, and reducing the chaff of comments, should be simple and safe ?
SARG
Posts: 1145
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.59 (15 APR 2012)

Postby SARG » May 19, 2012 2:10

MOD wrote: If using Scintilla is too much work, what about setting FB-keywords bold.


Ok, I'll try to do that. And if it's not too complicated (I guess it is not) also different colors for groups of keywords or for numerics and strings.

jmg wrote:source that is 'off' because it is inside conditionals, should not be highlighted.

Sorry, I don't understand. Could you post an example.

Same for this sentence :
jmg wrote:reducing the chaff of comments


jmg wrote:knowing at a glance which lines you can set a break point on

For now use the 'show executable lines' option in the source contextual menu
jmg
Posts: 89
Joined: Mar 11, 2009 3:42

Re: FB debugger : 2.59 (15 APR 2012)

Postby jmg » May 19, 2012 2:20

jmg wrote:knowing at a glance which lines you can set a break point on
For now use the 'show executable lines' option in the source contextual menu


Oops, forgot about that, in which case you already have most of my request covered.
- just a simple high-light of Keywords, and low-light of comments should do then.
Leave the frills to an editor.

If it is easier to do, you could try just BOLD for keywords, and italic for comments ?
SARG
Posts: 1145
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.59 (15 APR 2012)

Postby SARG » May 20, 2012 21:35

A beta 2.60 version with font selection, see in the settings option.

http://jafile.com/uploads/sarg/fbdebugger_2.60_beta.bas

MOD wrote:Sad, that it's just Windows only, sometimes I'd like to use it on Linux, too.

I'm curious to know if fbdebugger could be used with wine on a linux box. Someone to test ?
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Postby AGS » May 20, 2012 22:49

I ran into a thingy when using the debugger while running a program that uses a library (pcre) that contains debugging info. As I load the program I get message windows stating

Storing CUDT
Max limit reached 10000
OK


Then I get message windows stating

not found


and the title of those messages is

Source d:/pcre/pcre-8.10/pcre_get.bas


where the part pcre_get.bas varies (I get one message for every file inside the external library).

pcre_get.bas should be pcre_get.c . It's part of the pcre library (I compiled it myself and it builds with debugging symbols).

The previous two things are nothing more but 'interesting' events (the debugger did not crash and showed the BASIC source code correctly).

Stepping through the source using Step Over goes well until a call to a function inside the PCRE library occurs. I cannot step over the call to the function that resides in PCRE: the BASIC source code disappears and all I can do is keep on pressing the o until the program gets past the various calls made inside the PCRE library. When execution returns to the BASIC code I get to see the BASIC code again. Luckily it's just one function that behaved so badly (stepping over other functions from the PCRE library worked like a charm).

I can always use run-to-cursor to get rid of the step-over problem. If I position the cursor past a call to a PCRE routine and use run-to-cursor the source code does not disappear. But it is kinda hard to position the cursor on the correct statement. I am using -gen gcc and the cursor sometimes jumps around the source code when pressing s (and I am not even using -O 2).

I was happily surprised that the debugger could display an entire string in one window. Perhaps it would be even nicer if the string
would wrap around after a fixed number of bytes. The string I was viewing was kinda long so I had to scroll quite a bit.
But that's only a minor gripe. The string I was trying to view:
^(?P<preprocessor>#\s*((?P<include>include\s*(([\x22][^\x22]*?[\x22])|([\<][^\>]*?[\>])))|(?P<define>define)|(?P<ifdef>ifdef)|(?P<elif>elif)|(?P<ifndef>ifndef)|(?P<if>if)|(?P<error>error)|(?P<else>else)|(?P<undef>undef)|(?P<pragma>pragma)|(?P<endif>endif))((?P<ppcomment>/\*(.|(\r\n|\r|\n))*?\*/)|([^\\\r\n])|(\\[^\r\n])|(\\(\r\n|\r|\n)))*(\r\n|\r|\n))|^(?P<mcomment>/\*(.|(\r\n|\r|\n))*?\*/)|^(?P<scomment>//[^\r\n]*?(\r\n|\r|\n))|^(?P<space>[ ]+)|^(?P<tab>[\t]+)|^(?P<identifier>[a-zA-Z_][a-zA-Z0-9_]*)|^(?P<nline>\r\n|\r|\n)|^(?P<string_>[lL]?(\x22|\x27)(([\\]([\\]|\x22|\x27|[\?]|n|a|b|n|r|t|v|(x[a-fA-F0-9]+)|(0[0-7]+)|([Uu][a-fA-F0-9]+)))|[^\x22\x27])*?(\x22|\x27))|^(?P<onzin>123\$\$456)
SARG
Posts: 1145
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.60 BETA (20 MAY 2012)

Postby SARG » May 21, 2012 8:56

AGS wrote:I ran into a thingy when using the debugger while running a program that uses a library (pcre) that contains debugging info.......

Fbdebugger is not fully ready to use exes compiled with -gen GCC. There is still a lot of work.
So you got some known issues as the "Storing CUDT Max limit reached 10000" message and strange behaviour with the step commands.

I have already prepared 2 or 3 requests for the dev to improve debugging.

AGS wrote:I was happily surprised that the debugger could display an entire string in one window.
The displayed data should be limited to 32K.

AGS wrote:Perhaps it would be even nicer if the string would wrap around after a fixed number of bytes. But that's only a minor gripe.
I'll see if there is a parameter to automatically wrap. In negative case I don't know what I'll do.
SARG
Posts: 1145
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.60 BETA (20 MAY 2012)

Postby SARG » May 21, 2012 20:55

@AGS
I have just changed the style of the 'string' window removing the horizontal scrolling.
The lines are now wrapped if needed. Do some tests and tell me.

http://jafile.com/uploads/sarg/fbdebugg ... beta_2.bas
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: FB debugger : 2.60 BETA (20 MAY 2012)

Postby AGS » May 27, 2012 4:49

SARG wrote:@AGS
I have just changed the style of the 'string' window removing the horizontal scrolling.
The lines are now wrapped if needed. Do some tests and tell me.

http://jafile.com/uploads/sarg/fbdebugg ... beta_2.bas


Sorry about the late reaction. I just tested and it looks good.

Looking at the result I'm having all sorts of ideas to change it even more (think of things like highlighting matching parentheses, highlighting sequences of numbers and so forth and so on).

One idea comes to mind that I think will be good for all debugger users (the ones that want wrapping/the ones that don't want wrapping): a button to toggle wrapping. Yes wrap = no scrolling. No wrap = scrolling.

Your change is just what I wanted and perhaps others liked the scrolled window (don't know how much trouble it would be to have it both ways ie both scrolled- and not-scrolled).

As to the problems with -gen gcc: your debugger already does a good job at
-- demangling names of functions and subs
-- removing those vr$ variables and other stuff the user does not need to see.

In a program I tested the debugger cannot find the type of a variable when it's a static array. The type is 'unknown'. I checked with GDB and objdump -G (stabs dump) to find out info about the info on the variable (if there was any). And what I got was this:

GDB

Code: Select all

info scope MYMAIN$
Symbol OVECTOR$ is a local variable at frame offset -1624, length 1604.


And then

Code: Select all

(gdb) ptype OVECTOR$
type = int [401]


The type of OVECTOR is integer and it's an array size 401 (according to GDB).

The stabs info was a bit more of a puzzle to figure out. Using objdump -g I found

Code: Select all

int OVECTOR$[401]:uint32 /* 0xfffff9a8 */;


In raw stabs it's

Code: Select all

OVECTOR$:(0,52)=ar(0,28);0;400;(0,1)


ar(0,28) so it's an array of type 28. Of course there is the (0,52) which points to some tmp$ thingy. Which is interesting
but not necessary as ar(0,28) followed by 0;400; is all that is needed (array of type 28, low bound = 0, high bound = 400).
Type 28 is unsigned integer which is wrong but I might be wrong about that (stabs isn't my cup of tea).

Aside (but not unimportant): gcc has moved to dwarf2 format quite a long time ago (it's the default debugging output format) and even when compiling with stabs format you get some dwarf info. dwarf2 info for the variable from the example looks like this (in text) (DW_TAG is a tag, DW_AT is an attribute of that tag):

Code: Select all

 <2><b7d>: Abbrev Number: 9 (DW_TAG_variable)
    <b7e>   DW_AT_name        : OVECTOR$   
    <b87>   DW_AT_decl_file   : 1   
    <b88>   DW_AT_decl_line   : 0   
    <b89>   DW_AT_type        : <0x137c>   


The <2> means it is a continuation from the previous entry which is mymain$ (a function). The type (0x137c) refers to

Code: Select all

 <1><137c>: Abbrev Number: 14 (DW_TAG_array_type)
    <137d>   DW_AT_sibling     : <0x138d>   
    <1381>   DW_AT_type        : <0xad3>   
 <2><1385>: Abbrev Number: 15 (DW_TAG_subrange_type)
    <1386>   DW_AT_type        : <0xada>   
    <138a>   DW_AT_upper_bound : 400   


DW_TAG_array_type speaks for itself. Upper bound is 400 (<2> is continuation of <1>).
DW_AT_type 0xad3 refers to

Code: Select all

 <1><ad3>: Abbrev Number: 3 (DW_TAG_base_type)
    <ad4>   DW_AT_name        : int   
    <ad8>   DW_AT_byte_size   : 4   
    <ad9>   DW_AT_encoding    : 5   (signed)


So OVECTOR$ is a variable in functin mymain with an upper bound of 400 and a type of signed integer which is right. The dwarf info is the most exact info I could get (and it's easier to parse than the gdb output unless you create a gdb variable).

It's an investment (time) to go from stabs to dwarf2 but I think you'll find dwarf to be more structured and less hackish than stabs.

Having said that the devs still have to do something to keep track of names of variable names. Dwarf cannot find info that's not in the binary. Sorry about the long message.
SARG
Posts: 1145
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.60 BETA 2 (21 MAY 2012)

Postby SARG » May 29, 2012 22:33

@AGS
AGS wrote:Sorry about the late reaction....Sorry about the long message.

No problem : a late and long message is always better than no message ;-)

AGS wrote:One idea comes to mind that I think will be good for all debugger users (the ones that want wrapping/the ones that don't want wrapping): a button to toggle wrapping. Yes wrap = no scrolling. No wrap = scrolling.

The string window has now a button to toggle between wrapping/no wrapping.
http://jafile.com/uploads/sarg/fbdebugg ... beta_3.bas

AGS wrote:Looking at the result I'm having all sorts of ideas to change it even more (think of things like highlighting matching parentheses, highlighting sequences of numbers and so forth and so on).

Why not ? I put that in my todo list : the endless story.

About the -gen GCC option I'll see these issues but don't hope a quick return : I prefer spending time in the garden the weather is so good :-)


Some mods for the ir_hlc.bas, lines marked with SARG : suppress lines numbered zero, add names for dynamic arrays

Code: Select all

private sub hWriteLine _
   ( _
      byval s as zstring ptr = NULL, _
      byval addcommas as integer = TRUE, _
      byval noline as integer = FALSE _
   )

   static as string ln, idstr, dbgln

#macro writeToSection(ln)
   ' write it out to the current section
   select case as const ctx.section
   case SECTION_HEAD
      ctx.head_txt += ln
   case SECTION_BODY
      ctx.body_txt += ln
   case SECTION_FOOT
      ctx.foot_txt += ln
   end select
#endmacro
   if( s <> NULL ) then
      '' the redundancy here is needed to keep string allocated and speed up concatenation, DON'T CHANGE!

      if( ctx.identcnt > 0 ) then
         idstr = string( ctx.identcnt, TABCHAR )
      end if

      if( env.clopt.debug and noline = FALSE ) then
         if( ctx.identcnt > 0 ) then
            dbgln = idstr
            dbgln += "#line "
         else
            dbgln = "#line "
         end if

         dbgln += ctx.linenum & " """ & hReplace( env.inf.name, "\", "\\" ) & """" & NEWLINE

      'MODIF SARG GCC
         if ctx.linenum<>0 then
            writeToSection( dbgln )
         end if
      'END MODIF SARG

      end if

      if( ctx.identcnt > 0 ) then
         ln = idstr
         ln += *s
      else
         ln = *s
      end if

      if( addcommas ) then
         ln += ";"
      end if

      ln += NEWLINE

   else
      ln = NEWLINE
   end if

   writeToSection( ln )

end sub

=====
private sub hEmitVariable _
   ( _
      byval s as FBSYMBOL ptr _
   )
'Print  "SARG  " & *symbGetMangledName( s )
    '' already allocated?
   if( symbGetVarIsAllocated( s ) ) then
      return
   end if

   symbSetVarIsAllocated( s )

   '' literal? don't emit..
    if( symbGetIsLiteral( s ) ) then
       return
   end if

   '' initialized? only if not local or local and static
   if( symbGetIsInitialized( s ) and (symbIsLocal( s ) = FALSE or symbIsStatic( s ))  ) then

      '' extern or jump-tb?
       if( symbIsExtern( s ) ) then
         return
      elseif( symbGetIsJumpTb( s ) ) then
         return
      end if

       '' never referenced?
       if( symbIsLocal( s ) = FALSE ) then
          if( symbGetIsAccessed( s ) = FALSE ) then
            '' not public?
              if( symbIsPublic( s ) = FALSE ) then
                 return
              end if
         end if
      end if

        hEmitUDT( symbGetSubType( s ), typeIsPtr( symbGetType( s ) ) )

      astTypeIniFlush( s->var_.initree, _
                   s, _
                   AST_INIOPT_ISINI or AST_INIOPT_ISSTATIC )

      s->var_.initree = NULL
      return
   end if

    '' dynamic? only the array descriptor is emitted
   if( symbGetIsDynamic( s ) ) Then

      'MODIF SARG GCC
      hEmitVar( s )
      Dim stempo as FBSYMBOL Ptr
      stempo=s->Next
      If stempo<>0 Then
         While InStr(*symbGetMangledName( stempo),"tmp$" )=0
            stempo=stempo->Next
            If stempo=0 Then Return 'to avoid infinite loop
         Wend
         hWriteLine( "#define " & *symbGetMangledName( stempo ) & " " & "$$"&*symbGetMangledName( s ), FALSE )
      End If
      'END MODIF SARG
      Return
      
   end if

    '' a string or array descriptor?
   if( symbGetLen( s ) <= 0 ) then
      return
   end if

   hEmitVar( s )

end Sub
=======
private sub hEmitVregExpr _
   ( _
      byval vr as IRVREG ptr, _
      byref expr as string, _
      byval is_call as integer = FALSE _
   )

   if( irIsREG( vr ) ) then
      var ln = ""
      var typ = *hDtypeToStr( vr->dtype, vr->subtype )
      var id = hVregToStr( vr )

      if( is_call ) then
         ln = typ & " " & id & " = (" & typ & ")(" & expr & ");"
      else
         ln = "#define " & id & " ((" & typ & ")(" & expr & "))"
      end if

      hWriteLine( ln, FALSE, FALSE) 'MODIF SARG GCC
   else
      hWriteLine( hVregToStr( vr ) & " = (" & expr & ")" )
   end if

end Sub

=====
private sub _emitProcEnd _
   ( _
      byval proc as FBSYMBOL ptr, _
      byval initlabel as FBSYMBOL ptr, _
      byval exitlabel as FBSYMBOL ptr _
   )

   ctx.identcnt -= 1
   hWriteLine( "}", FALSE, FALSE ) 'MODIF SARG GCC

end Sub

AGS wrote:It's an investment (time) to go from stabs to dwarf2 but I think you'll find dwarf to be more structured and less hackish than stabs.

I'll have a look to dwarf but don't forget that it's not usable with the -gen gas. In the future if this option disappear, it would be effectively better.
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: FB debugger : 2.60 BETA 2 (21 MAY 2012)

Postby AGS » Jun 09, 2012 7:27

SARG wrote:About the -gen GCC option I'll see these issues but don't hope a quick return : I prefer spending time in the garden the weather is so good :-)


:) Looking at the discussion concerning the deprecation of the asm back end not that many fb programmers are willing to let go of -gen gas. And as the devs are not willing to let go either (they're updating both asm- and c back end) -gen gcc might not get used all that often.

Pity I don't have a garden to spend time in :(
TJF
Posts: 3601
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: FB debugger : 2.60 BETA 2 (21 MAY 2012)

Postby TJF » Jun 09, 2012 8:46

AGS wrote:Pity I don't have a garden to spend time in :(

Laiko and me welcome you in our virtual garden

SARG
Posts: 1145
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.60 BETA 3 (30 MAY 2012)

Postby SARG » Jun 22, 2012 22:02

Hi all,

A new beta http://jafile.com/uploads/sarg/fbdebugg ... beta_6.bas

What's new :
- The basis for highlighting keywords, use the option 'about' (a bit lazy). List to be completed, I got it but I must find a good way of integration.
- An option 'focus line' (shortkey L) in the source window opens a window to follow the executed line or an other part of any source module. This window hasn't the horizontal scrolling style to avoid scrolling.
- In settings, a button to change the background source window color, saved in the ini file. The beginning of color management.

Note: I'll have no access to internet for a few days so don't expect quick replies.
VANYA
Posts: 1375
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: FB debugger : 2.60 BETA 6 (23 JUNE 2012)

Postby VANYA » Jun 23, 2012 4:15

Hello SARG!

Excellent! Good add-on. While the lights are not for all words, not for (endif, with and may have any).

I have two questions:

1) I then tried to debug the application is Unicode, but it looks like the debugger does not know how to work with Unicode?
2) I have not found ... The debugger can debug multithreaded applications?
St_W
Posts: 1504
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: FB debugger : 2.60 BETA 6 (23 JUNE 2012)

Postby St_W » Jun 24, 2012 21:54

Hi SARG,

first I have to say that your debugger is a great piece of software and thank your effort you have put into this.

But I have an issue for you, which I ran into recently.
I sometimes use FB's Asm blocks to insert comments into the generated ASM-intermediate-code to find certain code locations easier there. The following code is an simplified example:

Code: Select all

Dim a As UInteger = 1
Dim b As UInteger = 2

Asm
   /*begintest*/
End Asm
b = a
Asm
   /*endtest*/
End Asm

Print a

Sleep

When I tried to debug that program using the latest version of your debugger (2.60 beta 6) the program hangs at "Print a" (fbdebugger marks that as current execution position at least). When using "Step over", "Release" or others I also ran into this problem.
When I removed one asm comment fbdebugger works, but behaves strange.
When removing both asm comments it works just fine.


I wonder whether this is a problem of your debugger or fbc (as generating STABS info) and if there's a solution.
But solving the problem is not very important in my opinion, because one could easily avoid it by just not using asm comments in FB.
TJF
Posts: 3601
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: FB debugger : 2.60 BETA 6 (23 JUNE 2012)

Postby TJF » Jun 25, 2012 6:05

St_W wrote:..., because one could easily avoid it by just not using asm comments in FB.

Instead of a comment you can declare a specific variable (just to mark the position)

Code: Select all

Dim a As UInteger = 1
Dim b As UInteger = 2

ASM begintest = .

b = a

ASM endtest = .

Print a

Sleep

Return to “Projects”

Who is online

Users browsing this forum: No registered users and 1 guest