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 > Non-x86 architectures > FASMARM v1.42 - Cross assembler for ARM CPUs

Goto page Previous  1, 2, 3 ... 26, 27, 28, 29  Next
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15324
Location: Bigweld Industries


Andrew Martin wrote:
Does the type of macro matter?

Yes, very much so.

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.
Post 07 Oct 2015, 14:20
View user's profile Send private message Visit poster's website Reply with quote
Andrew Martin



Joined: 30 Sep 2015
Posts: 29
Location: 404, Lugansk


revolution wrote:


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.



It`s pure hardcore Shocked
Post 07 Oct 2015, 20:09
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


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

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.

But because I had no existing format that I had to follow, I chose to just dump some of fasm's internal structures with little to no conversion and that's what the "fas" format is. This made the implementation quite simple but at the price of making it a format that is only really applicable to fasm 1.x. So because there were no existing formats that were universal enough, I created another one that is also not universal in the slightest - it is only there to contain some types of information specific to fasm 1.x. Perhaps if I ever think about making a debug information format for my new assembly engine I should try to design something more clean and generalized.
Post 08 Oct 2015, 10:30
View user's profile Send private message Visit poster's website Reply with quote
Andrew Martin



Joined: 30 Sep 2015
Posts: 29
Location: 404, Lugansk

A problem with an elf again Sad

.symtab header is broken.


readelf log:


Code:

Section Headers:
  [NrName              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 requiredo (OS specific), p (processor specific)

Symbol table '.symtab' contains 7 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     100000000     0 OBJECT  LOCAL  DEFAULT    1 $d
     200000008     0 FILE    <unknown>: 3 DEFAULT    1 $t
     30000000c     0 OBJECT  LOCAL  DEFAULT    1 $d
     400000000     0 FUNC    LOCAL  DEFAULT    1 __Vectors
     50000000c     0 FUNC    LOCAL  DEFAULT    1 lbl
     600000008     0 FUNC    LOCAL  DEFAULT    1 Reset_Handler





1) invalid sh_info member in .symtab section header
2) invalid st_info member in symbol table entry №2 (binding attribute). Possible Name also invalid (may be test.asm).

Test files:


Description: Test source + ELF DWARF executable
Download
Filename: test.zip
Filesize: 1.15 KB
Downloaded: 168 Time(s)



Last edited by Andrew Martin on 12 Nov 2015, 12:45; edited 1 time in total
Post 09 Nov 2015, 17:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15324
Location: Bigweld Industries

Questions related to Linux and ioctl have been moved. See:
http://board.flatassembler.net/topic.php?t=18712
Post 12 Nov 2015, 12:21
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: 15324
Location: Bigweld Industries


Andrew Martin wrote:
A problem with an elf again Sad
<...>
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).

I'll look into it.
Post 12 Nov 2015, 12:47
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: 15324
Location: Bigweld Industries


Tomasz Grysztar wrote:
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.

Yes, the fas format is very detailed. But none of the existing tools know about it. The DWARF format doesn't support such a level detail, so there has to be some reduction of detail to make the output workable with existing things.
Post 12 Nov 2015, 12:50
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: 15324
Location: Bigweld Industries

v1.37

Version 1.37 now available:

Quote:
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

Note that this version assembles against fasm v1.71.47
Post 16 Nov 2015, 04:44
View user's profile Send private message Visit poster's website Reply with quote
Andrew Martin



Joined: 30 Sep 2015
Posts: 29
Location: 404, Lugansk

It is possible to add the attribute DW_AT_comp_dir with full path name of main source file?
Post 16 Nov 2015, 12:37
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15324
Location: Bigweld Industries


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

The short answer is yes. But currently the base fasm file 'SYSTEM.INC' does not expose the path to the core. Adding it would require editing all of the 'SYSTEM.INC' files in each of the OS platforms and interfacing with the OS to obtain the base path being used.
Post 16 Nov 2015, 13:18
View user's profile Send private message Visit poster's website Reply with quote
Andrew Martin



Joined: 30 Sep 2015
Posts: 29
Location: 404, Lugansk

My MCU debugger (Keil uVision) does not find the source files when load *.axf generated by FASMARM.
However, it find source files when load *.axf generated by GNU assembler (gas) + LD linker or ARMASM+ARMLINK.
Tools with strict requirements to the ELF&DWARF format specification does not works correctly. Something in ELF or DWARF still incorrect.
I think that reason is in an attribute DW_AT_comp_dir. Maybe I'm wrong...
Post 16 Nov 2015, 16:10
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15324
Location: Bigweld Industries

The compilation directory is not mandatory. And the format is platform specific. If you compile a file on one system and use DW_AT_comp_dir then you can't use that file on another system because the paths will be unlikely to match.
Post 16 Nov 2015, 16:44
View user's profile Send private message Visit poster's website Reply with quote
Andrew Martin



Joined: 30 Sep 2015
Posts: 29
Location: 404, Lugansk

In most cases debug followed immediately after compilation on the same computer, so systems the same.
Post 16 Nov 2015, 19:34
View user's profile Send private message Reply with quote
Andrew Martin



Joined: 30 Sep 2015
Posts: 29
Location: 404, Lugansk

My debugger (Keil uVision) dont likes that:
- the labels addresses in the symbols table are even (perhaps because THUMB mode);
- all labels have LOCAL binding, but labels in source code must have GLOBAL binding;
- incorrect line number program end

From DWARF-2 specification:

Code:

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.





For example, GAS produces:

Code:

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



Last machine instruction address = 0x8, machine instruction size = 2 bytes
Last row address = 0xA

FASMARM:


Code:

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





Last machine instruction address = 0x8, machine instruction size = 2 bytes,
but last row address = 0x8.
Post 26 Nov 2015, 11:40
View user's profile Send private message Reply with quote
Andrew Martin



Joined: 30 Sep 2015
Posts: 29
Location: 404, Lugansk

Another invalid ELF example - possibly in symbol table and line number program.


Description:
Download
Filename: test103.zip
Filesize: 51.8 KB
Downloaded: 166 Time(s)

Post 03 Dec 2015, 11:33
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15324
Location: Bigweld Industries

Thanks for the reports. When I am back at my desk I will look into these.
Post 03 Dec 2015, 13: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: 15324
Location: Bigweld Industries

Well I lied. I haven't yet got back to my desk. But anyhow, Andrew Martin, can you please try with this binary file and see if your issue(s) are better (and/or worse Confused)


Description: Remove the .txt extension
Download
Filename: main103.axf.txt
Filesize: 1.86 KB
Downloaded: 151 Time(s)

Post 05 Dec 2015, 03:39
View user's profile Send private message Visit poster's website Reply with quote
Andrew Martin



Joined: 30 Sep 2015
Posts: 29
Location: 404, Lugansk

Much better, but invalid sh_info member in .symtab section header.
Post 05 Dec 2015, 15:27
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15324
Location: Bigweld Industries


Andrew Martin wrote:
Much better, but invalid sh_info member in .symtab section header.

Okay. So the byte at offset 0x73c should be changed from 0x21 to 0x10 (the index of the first global symbol)? Can you try that value?
Post 05 Dec 2015, 17:25
View user's profile Send private message Visit poster's website Reply with quote
Andrew Martin



Joined: 30 Sep 2015
Posts: 29
Location: 404, Lugansk

Yes. Now (with 0x10) almost all OK Smile
Post 05 Dec 2015, 18:27
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3 ... 26, 27, 28, 29  Next

< 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-2017, Tomasz Grysztar.