flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Compiler Internals > Error reporting with macro lines (spin-off thread)

Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14462
Location: Eta Argus
I think it is important to display the source line, the preprocessed line and the source filename for all lines involved. I have situations in fasm where I get only the source line and filename displayed with an error about some invalid thing. I sometimes find it impossible to back-trace to the original error line. For example this is a real error that I got recently:

Code:
flat assembler for ARM  version 1.40 (built on fasm 1.71.52)  (3145344 kilobytes memory)
test.asm [733]:

Macros.inc [980postpone [87]:
        string_list
Macros.inc [864string_list [2]:
                        m\\#x
Macros.inc [864rept [1]:
                        m\\#x
Macros.inc [859m?8b310 [0]:
                        macro m\\#x a
Macros.inc [545dbs [4]:
                . db string
errorextra characters on line.

The actual error is in another file (not given in the message) with the line "call some_function,<'%s:'13,10>" (note there is no comma before the 13). With the error printed as shown above there is no clue as the the actual problem location.
Post 24 Sep 2016, 21:15
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

revolution wrote:
I think it is important to display the source line, the preprocessed line and the source filename for all lines involved. I have situations in fasm where I get only the source line and filename displayed with an error about some invalid thing. I sometimes find it impossible to back-trace to the original error line. For example this is a real error that I got recently:

Code:
flat assembler for ARM  version 1.40 (built on fasm 1.71.52)  (3145344 kilobytes memory)
test.asm [733]:

Macros.inc [980postpone [87]:
        string_list
Macros.inc [864string_list [2]:
                        m\\#x
Macros.inc [864rept [1]:
                        m\\#x
Macros.inc [859m?8b310 [0]:
                        macro m\\#x a
Macros.inc [545dbs [4]:
                . db string
errorextra characters on line.

The actual error is in another file (not given in the message) with the line "call some_function,<'%s:'13,10>" (note there is no comma before the 13). With the error printed as shown above there is no clue as the the actual problem location.

I can add an option to command line fasm that would enable displaying the preprocessed line like fasmw does - fasmw is currently the only interface that shows this information.
Post 24 Sep 2016, 21:18
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14462
Location: Eta Argus

Tomasz Grysztar wrote:
I can add an option to command line fasm that would enable displaying the preprocessed line like fasmw does - fasmw is currently the only interface that shows this information.

This would be good and would help towards finding the error. But I would prefer if it is on by default. But more than that is the problem of not actually displaying the file and line number where the problem is situated. Having the preprocessed output might help and allow one to search all the source files for the matching string, but it is error prone and tedious.

For that specific error I only found where the error was because I had only made a few changes between assembly sessions and could narrow down the problem relatively quickly. But for cases of automated source generation it can be an enormous task to find such things.
Post 24 Sep 2016, 21:25
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

revolution wrote:
This would be good and would help towards finding the error. But I would prefer if it is on by default. But more than that is the problem of not actually displaying the file and line number where the problem is situated. Having the preprocessed output might help and allow one to search all the source files for the matching string, but it is error prone and tedious.

When the value comes from some symbolic variable that was redefined many times, you would not get any sensible information about the initial line anyway. The only hint you could get would be that preprocessed line content with '%s:'13 phrase in it. A method that I sometimes used would be to add a code next to the offending ". db string" to display the content of "string". But fasmw's preprocessed display provides similar information immediately.
Post 24 Sep 2016, 21:30
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14462
Location: Eta Argus
In the case above the value for "string" comes from a macro parameter using the list building macros I posted in another thread. It isn't a redefined symbolic variable. Although the macro name is dynamically generated.
Post 24 Sep 2016, 21:35
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland
You could probably use the information from fas then - the header of every macro-generated line contains two pointers: to the line that called the macro, and to the line that defined the line of macro that generated this one. This creates a binary tree structure of lines, displaying it all for normal error report would be a mess, but perhaps some tool with interactive UI that would extract this information from .fas and present the whole tree could help here a lot.
Post 24 Sep 2016, 21:49
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14462
Location: Eta Argus
Okay for the fas solution, but it doesn't exist right now, and it feels like kind of a heavy duty solution to something that could be made much lighter and happen by default.

However the original post was in the fasmg thread. And since fasmg is 100% macros then I think this becomes even more important within fasmg to help the user find the problem easily.

Edit: Also since fasmg is much slower there is less enthusiasm towards assembling frequently so more changes will likely happen between assembly sessions. fasm is fast enough that a user could assemble every few minutes without any difficulty, so such errors caused by editing can still be in the users short term memory, easing the pain a little.
Post 24 Sep 2016, 22:01
View user's profile Send private message Visit poster's website Reply with quote
jmg



Joined: 18 Sep 2016
Posts: 61

revolution wrote:
..
However the original post was in the fasmg thread. And since fasmg is 100% macros then I think this becomes even more important within fasmg to help the user find the problem easily.



I'm all for improving the fasmg reporting Smile

It should report the offending string & I think a column number would help too.
maybe [Line,Col] ?
Some assemblers/compilers also print 2 lines, with a Caret ^ in the second line, that easily shows the error Column number, saving counting chars....

If there is a chance the string is not in the originating file, then yes, it should include a file name prefix.
Post 24 Sep 2016, 23:29
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

revolution wrote:
Okay for the fas solution, but it doesn't exist right now, and it feels like kind of a heavy duty solution to something that could be made much lighter and happen by default.

I don't know what kind of lighter solution you have in mind, as it is certainly not an obvious one. How to present the tree of line relations in a way that would be readable and not too intimidating? And fitting it on a console screen is probably out of question.
To look at some real example, compare this description of a definition of a single symbol from fasmw.fas generated by "symbols" tool, the only one so far where I attempted to present the whole tree of relations:

symbols.exe wrote:
..var?YX: -0x0000000000000149+ebp, defined in {line generated by {line generated by {line generated by {line generated by {line generated by {line generated by {line generated by {line generated by {line generated by C:\Program Files (x86)\fasm\SOURCE\IDE\FASMW\fedit.inc[67] from {line generated by {line generated by {line generated by {line generated by {line generated by {line generated by {line generated by C:\Program Files (x86)\fasm\INCLUDE/equates/user32.inc[226] from C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[68]}}} from C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[86]}} from C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[119]}}}}} from {line generated by {line generated by {line generated by {line generated by {line generated by {line generated by {line generated by C:\Program Files (x86)\fasm\INCLUDE/equates/user32.inc[12] from C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[68]}}} from C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[86]}} from C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[124]}}}} from {line generated by C:\Program Files (x86)\fasm\SOURCE\IDE\FASMW\fedit.inc[15] from {line generated by {line generated by {line generated by C:\Program Files (x86)\fasm\SOURCE\IDE\FASMW\fedit.inc[13] from C:\Program Files (x86)\fasm\INCLUDE/macro/proc32.inc[53]}} from C:\Program Files (x86)\fasm\INCLUDE/macro/proc32.inc[116]}}}} from C:\Program Files (x86)\fasm\INCLUDE/macro/proc32.inc[183]} from C:\Program Files (x86)\fasm\INCLUDE/macro/proc32.inc[195]}




revolution wrote:
However the original post was in the fasmg thread. And since fasmg is 100% macros then I think this becomes even more important within fasmg to help the user find the problem easily.

In case of fasmg there is much less that can be discussed, because as it was noted recently, fasmg does not maintain an entire preprocessed source text like fasm did, so the information about the tree of line connections in not readily available and tracking it would be quite costly. What is available is the preprocessed content of the currently processed line and this is something that may often provide helpful information, so it is perhaps worth it to present it by default - but I need to do it in a clean way. I chose to keep the report of a single error relatively concise, because fasmg, unlike fasm, also allows to report many errors at once.
Post 25 Sep 2016, 07:37
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14462
Location: Eta Argus
Showing trees in text can be clearer when using indenting:

Code:
..var?YX: -0x0000000000000149+ebp, defined in {
  line generated by {
    line generated by {
      line generated by {
        line generated by {
          line generated by {
            line generated by {
              line generated by {
                line generated by {
                  line generated by C:\Program Files (x86)\fasm\SOURCE\IDE\FASMW\fedit.inc[67] from {
                    line generated by {
                      line generated by {
                        line generated by {
                          line generated by {
                            line generated by {
                              line generated by {
                                line generated by C:\Program Files (x86)\fasm\INCLUDE/equates/user32.inc[226] from C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[68]
                              }
                            }
                          } from C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[86]
                        }
                      } from C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[119]
                    }
                  }
                }
              }
            } from {
              line generated by {
                line generated by {
                  line generated by {
                    line generated by {
                      line generated by {
                        line generated by {
                          line generated by C:\Program Files (x86)\fasm\INCLUDE/equates/user32.inc[12] from C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[68]
                        }
                      }
                    } from C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[86]
                  }
                } from C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[124]
              }
            }
          }
        } from {
          line generated by C:\Program Files (x86)\fasm\SOURCE\IDE\FASMW\fedit.inc[15] from {
            line generated by {
              line generated by {
                line generated by C:\Program Files (x86)\fasm\SOURCE\IDE\FASMW\fedit.inc[13] from C:\Program Files (x86)\fasm\INCLUDE/macro/proc32.inc[53]
              }
            } from C:\Program Files (x86)\fasm\INCLUDE/macro/proc32.inc[116]
          }
        }
      }
    } from C:\Program Files (x86)\fasm\INCLUDE/macro/proc32.inc[183]
  } from C:\Program Files (x86)\fasm\INCLUDE/macro/proc32.inc[195]
}

And if the actual source lines and the preprocessed version at each point were included, and the blank portions eliminated, then it can be quite clear IMO. At the very least one wouldn't have to go hunting through every source file in the hierarchy to find the error, the search can be restricted to just the files shown in the tree output.
Post 25 Sep 2016, 07:55
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14462
Location: Eta Argus
Alternatively you could restrict the output to just the source lines. Here it is without duplicate lines removed:

Code:
..var?YX: -0x0000000000000149+ebppossibly defined at
  C:\Program Files (x86)\fasm\SOURCE\IDE\FASMW\fedit.inc[67]
  C:\Program Files (x86)\fasm\INCLUDE/equates/user32.inc[226]
  C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[68]
  C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[86]
  C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[119]
  C:\Program Files (x86)\fasm\INCLUDE/equates/user32.inc[12]
  C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[68]
  C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[86]
  C:\Program Files (x86)\fasm\INCLUDE/macro/struct.inc[124
  C:\Program Files (x86)\fasm\SOURCE\IDE\FASMW\fedit.inc[15]
  C:\Program Files (x86)\fasm\SOURCE\IDE\FASMW\fedit.inc[13]
  C:\Program Files (x86)\fasm\INCLUDE/macro/proc32.inc[53]
  C:\Program Files (x86)\fasm\INCLUDE/macro/proc32.inc[116]
  C:\Program Files (x86)\fasm\INCLUDE/macro/proc32.inc[183]
  C:\Program Files (x86)\fasm\INCLUDE/macro/proc32.inc[195]

Post 25 Sep 2016, 08:01
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland
You could try modding fasm and if you find a variant that seems good, I'll be happy to give it a look. Thus far I'm not yet convinced.
Post 25 Sep 2016, 08:26
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14462
Location: Eta Argus
I will look into it. Maybe in a few years I'll come back here with something.
Post 25 Sep 2016, 10:48
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6179
Location: Kraków, Poland

revolution wrote:
I will look into it. Maybe in a few years I'll come back here with something.

That's OK, it would be a similar delay to the one I have with all fasm-related releases nowadays. Wink
Post 25 Sep 2016, 13:24
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.