Does the type of macro matter?

For example if one were to use the list building macros (posted in another thread) to build code and data sections then the entire code section becomes one single macro. So listing a macro invocation as some type of self contained unit would make debugging with line numbers and symbols useless.

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000054 000010 00  AX  0   0  4
  [ 2] .shstrtab         STRTAB          00000000 000064 000048 00      0   0  0
  [ 3] .debug_abbrev     PROGBITS        00000000 0000ac 000010 00      0   0  0
  [ 4] .debug_info       PROGBITS        00000000 0000bc 000068 00      0   0  0
  [ 5] .debug_line       PROGBITS        00000000 000124 00003c 00      0   0  0
  [ 6] .symtab           SYMTAB          00000000 000160 000070 10      7  12  4
  [ 7] .strtab           STRTAB          00000000 0001d0 00002c 00      0   0  0
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Symbol table '.symtab' contains 7 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000     0 OBJECT  LOCAL  DEFAULT    1 $d
     2: 00000008     0 FILE    <unknown>: 3 DEFAULT    1 $t
     3: 0000000c     0 OBJECT  LOCAL  DEFAULT    1 $d
     4: 00000000     0 FUNC    LOCAL  DEFAULT    1 __Vectors
     5: 0000000c     0 FUNC    LOCAL  DEFAULT    1 lbl
     6: 00000008     0 FUNC    LOCAL  DEFAULT    1 Reset_Handler

    

A problem with an elf again
<...>
1) invalid sh_info member for .symtab section header
2) invalid st_info member for symbol table entry №2 (binding attribute). Possible Name also invalid (may be test.asm).

It is one of the reasons why I decided to create the fas format - because the existing debug information formats were not entirely capable of containing the kind of information fasm may provide. From the .fas file you can deduce both the line that called a macro, and a line in definition of a macro that generated the specific byte. Or perhaps a whole sequence of line numbers for macros called from inside macros. And in some cases the definition of a macro was itself generated by another macro and then you have another tree of lines that were the "source" for a given line in macro, which in turn was a source for some final instruction that got assembled, etc.

v1.37 2015-Nov-16

• Added code and data generation from macro lines to the line number information table
• Fixed a bug with elf dwarf format symbol table corruption
• Fixed a bug where post-update instructions with a positive sign (eg. ldr r0,[r1],+r2) would always be forced negative
  

It is possible to add the attribute DW_AT_comp_dir with full path name of main source file?

DW_LNE_end_sequence
Set the end_sequence register of the state machine to ‘‘true’’ and append a row to the
matrix using the current values of the state-machine registers. Then reset the registers to
the initial values specified above.

Every statement program sequence must end with a DW_LNE_end_sequence
instruction which creates a row whose address is that of the byte after the last target
machine instruction of the sequence.
    

 Line Number Statements:
  [0x00000029]  Extended opcode 2: set Address to 0x8
  [0x00000030]  Advance Line by 15 to 16
  [0x00000032]  Copy
  [0x00000033]  Advance PC by 2 to 0xa
  [0x00000035]  Extended opcode 1: End of Sequence    

Line Number Statements:
  [0x00000026]  Advance Line by 47 to 48
  [0x00000028]  Copy
  [0x00000029]  Advance Line by 7 to 55
  [0x0000002b]  Special opcode 48: advance Address by 8 to 0x8 and Line by 0 to 55
  [0x0000002c]  Extended opcode 1: End of Sequence

    

Much better, but invalid sh_info member in .symtab section header.