Error reporting with macro lines (spin-off thread)

Index > Compiler Internals > Error reporting with macro lines (spin-off thread)

Author

Thread

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20620
Location: In your JS exploiting you and your system

revolution 24 Sep 2016, 21:15

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 [980] postpone [87]:
        string_list
Macros.inc [864] string_list [2]:
                        m\\#x
Macros.inc [864] rept [1]:
                        m\\#x
Macros.inc [859] m?8b310 [0]:
                        macro m\\#x a
Macros.inc [545] dbs [4]:
                . db string
error: extra 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.

24 Sep 2016, 21:15

Tomasz Grysztar

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

Tomasz Grysztar 24 Sep 2016, 21:18

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 [980] postpone [87]:
        string_list
Macros.inc [864] string_list [2]:
                        m\\#x
Macros.inc [864] rept [1]:
                        m\\#x
Macros.inc [859] m?8b310 [0]:
                        macro m\\#x a
Macros.inc [545] dbs [4]:
                . db string
error: extra 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.

24 Sep 2016, 21:18

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20620
Location: In your JS exploiting you and your system

revolution 24 Sep 2016, 21:25

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.

24 Sep 2016, 21:25

Tomasz Grysztar

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

Tomasz Grysztar 24 Sep 2016, 21:30

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.

24 Sep 2016, 21:30

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20620
Location: In your JS exploiting you and your system

revolution 24 Sep 2016, 21:35

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.

24 Sep 2016, 21:35

Tomasz Grysztar

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

Tomasz Grysztar 24 Sep 2016, 21:49

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.

24 Sep 2016, 21:49

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20620
Location: In your JS exploiting you and your system

revolution 24 Sep 2016, 22:01

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.

24 Sep 2016, 22:01

jmg

Joined: 18 Sep 2016
Posts: 62

jmg 24 Sep 2016, 23:29

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.

24 Sep 2016, 23:29

Tomasz Grysztar

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

Tomasz Grysztar 25 Sep 2016, 07:37

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.

25 Sep 2016, 07:37

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20620
Location: In your JS exploiting you and your system

revolution 25 Sep 2016, 07:55

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.

25 Sep 2016, 07:55

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20620
Location: In your JS exploiting you and your system

revolution 25 Sep 2016, 08:01

Alternatively you could restrict the output to just the source lines. Here it is without duplicate lines removed:

Code:

..var?YX: -0x0000000000000149+ebp, possibly 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]

25 Sep 2016, 08:01

Tomasz Grysztar

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

Tomasz Grysztar 25 Sep 2016, 08:26

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.

25 Sep 2016, 08:26

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20620
Location: In your JS exploiting you and your system

revolution 25 Sep 2016, 10:48

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

25 Sep 2016, 10:48

Tomasz Grysztar

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

Tomasz Grysztar 25 Sep 2016, 13:24

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

25 Sep 2016, 13:24

< 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