Is there a way to see the generated ".s" assembly files as Intel syntax instead of the AT&T one?
The -Rintel flag does not seem to work, or I am doing something wrong.

Tried command line and fpc.cfg both, on win32 and win64, latest SVN .

what command line, exactly, please?

21.08.2012 5:38, ABorka пишет:

-R switch controls parsing assembler blocks in the code. The output format is set with -A (e.g. -Amasm will produce Intel syntax).

Regards,
Sergei

For example

fpc -Rintel -alr -MObjFPC -Scgi -O1 -Twin32 -Pi386 -g -gl -WG -vewnhi -l -FuC:\...something... -FuC:\lazarus\lcl\units\i386-win32\win32 -FuC:\lazarus\lcl\units\i386-win32
-FuC:\lazarus\components\lazutils\lib\i386-win32
-FuC:\lazarus\packager\units\i386-win32 -FuC:\...something...\ -FUC:\...something...\lib\i386-win32\ -oMyProgram-win32.exe -dLCL -dLCLwin32 MyProgram.lpr

The "*.s" files are there, but all are in AT&T syntax, not Intel

Tried to put
-Rintel
and
-alr
into the fpc.cfg also, with the same result.

That requires masm to compile the project.

What I actually want is to see the disassembled code from my project (as Intel Syntax assembly code) to look at how the win32 and win64 code is optimized and then to fine tune the pascal source.

1. The objdump ("objdump.exe" and "x86_64-win64-objdump.exe") utility from the binutils programs works and displays the code with the -Mintel option as Intel syntax from the "*.o" files, however when I try to see the line numbers (objdump.exe -l ...) and source code lines (objdump.exe -S ...) it does not put them in the right places within the disassembled code.

As an example, I used:
objdump.exe -d -Mintel -w -l -S -EL something.o > something.disassembled

2. The fpc "-al" flag generates a nice "*.s" assembler file during compilation, where everything is in place, except it is not Intel syntax assembly but AT&T.

Anyone had experience with something like this (display the disassembled code of a project unit/object_file in Intel syntax, with source code lines)?

Thanks for any help

Only if the compiler calls the assembler. You can use the -s parameter to prevent it from doing that.

Jonas

21.08.2012 10:32, ABorka пишет:

That requires masm to compile the project.

Likewise, using "-al" requires GNU AS to compile. The latter is typically installed together with FPC, so it just works transparently.

What I actually want is to see the disassembled code from my project (as Intel Syntax assembly code) to look at how the win32 and win64 code is optimized and then to fine tune the pascal source.

FPC does not generate *disassembled* code. It generates code that is subject to be assembled - either with internal assembler or by one of external tools.

"-al" (and in general any "-a") switch implies using an external assembler, which is GNU AS by default on most targets. It can be overridden with "-A". Thus, "-al -Amasm" will generate MASM format listing with line information inserted.

For the purposes of reading assembler source you can also add "-s" switch, which will stop after producing the listing (MASM output probably won't assemble even if you have ml.exe available).

This may be an issue to fix (or maybe not, given that gdb usually locates source lines correctly using the same line information from the object files).

Regards,
Sergei

This is exactly what I needed.
"-alr -sr -Amasm" does it. I just put them into my "fpc.cfg" .

Thanks for all the help guys.

It would be nice to see it work with objdump also, but not a priority. With your help guys I was able to get the needed output using the fpc.cfg and the FPC parameters you guys mentioned.

Thanks for the help

<...snip...>

<...snip...>

ABorka wrote

This is exactly what I needed. "-alr -sr -Amasm" does it. I just put them into my "fpc.cfg" .

Why did you put this into your fpc.cfg? You are aware that with the "-s" switch no binary code is generated? Or are you protecting that with an IFDEF?

Regards,
Sven

Yes, you are right.
I just comment out the options within fpc.cfg after I got the asm files (*.s) for study.