how to related icc -S assembly code and objdump linked assembly code quickly?

[sun__lei]

As we all know, icc -S will print assembly code with symbol address not physical address. Such as:

..B1.20: 
        movslq    %r8d, %rax                                    #10.3        

        .align    16,0x90

..B1.21:                              

                movups    (%rdx,%rsi,8), %xmm0                          #11.12        

                movups    16(%rdx,%rsi,8), %xmm1                        #11.12

When using objdump -S ./xx.bin, the related assembly code as:

 402024:   49 63 c0                movslq %r8d,%rax 

402027:   66 0f 1f 84 00 00 00    nopw   0x0(%rax,%rax,1)  

40202e:   00 00  

402030:   0f 10 04 f2             movups (%rdx,%rsi,8),%xmm0  

402034:   0f 10 4c f2 10          movups 0x10(%rdx,%rsi,8),%xmm1

But the related process is so boring.  Is there a good way to relate the two? May icc compiler generate  linked assembly code with physical address?

[AbhishekD_Intel]

Hi,

Will you please elaborate on what specifically you want to achieve so that we can help you out.

Regards,

Abhishek

[jimdempseyatthecove]

>>May icc compiler generate  linked assembly code with physical address?

icc generates object code (and intermediary files like precompiled headers, and optional output source files), not execuitables.
The linker combines the object code into an image.

>>But the related process is so boring.  Is there a good way to relate the two?

If you select in Output Files, Assembler Output: Machine Code with Source you get:

                                ; LOE rsi rdi r12 r13 r14 xmm6 xmm7 xmm8 xmm9 xmm10 xmm11 xmm12 xmm13 xmm14 xmm15
.B1.49::                        ; Preds .B1.1
                                ; Execution count [1.00e+000]
  00017 0f ae 5c 24 50   stmxcsr DWORD PTR [80+rsp]             ;C:\test\FConsole1\FConsole1\FConsole1.f90:2.13
  0001c 48 8d 0d 00 00 
        00 00            lea rcx, QWORD PTR [__NLITPACK_0.0.1]  ;C:\test\FConsole1\FConsole1\FConsole1.f90:2.13
  00023 81 4c 24 50 40 
        80 00 00         or DWORD PTR [80+rsp], 32832           ;C:\test\FConsole1\FConsole1\FConsole1.f90:2.13
  0002b 0f ae 54 24 50   ldmxcsr DWORD PTR [80+rsp]             ;C:\test\FConsole1\FConsole1\FConsole1.f90:2.13

The above was with Fortran, C++ would give similar output.

Note, the address field (00017, 0001c, ...) is the offset within the 'CODE' segment. Static data and initialized data will be located in different segments.

The base address for each segment is determined at Link time. It should be relatively easy for any programmer to write a program to obtain the base address for each segment in the Linker map file output, and then to convert the offset values to image virtual addresses, and output to a new file.

Jim Dempsey

[sun__lei]

Thanks for your reply. But I want to found the way icc print linked assemble code like the objdump ,but also keep icc -S assemble code comments. Your way also need to calculate virtual address by hand and it is not direct. Thank you again.

jimdempseyatthecove (Blackbelt) wrote:

>>May icc compiler generate  linked assembly code with physical address?

icc generates object code (and intermediary files like precompiled headers, and optional output source files), not execuitables.
The linker combines the object code into an image.

>>But the related process is so boring.  Is there a good way to relate the two?

If you select in Output Files, Assembler Output: Machine Code with Source you get:

                                ; LOE rsi rdi r12 r13 r14 xmm6 xmm7 xmm8 xmm9 xmm10 xmm11 xmm12 xmm13 xmm14 xmm15
.B1.49::                        ; Preds .B1.1
                                ; Execution count [1.00e+000]
  00017 0f ae 5c 24 50   stmxcsr DWORD PTR [80+rsp]             ;C:\test\FConsole1\FConsole1\FConsole1.f90:2.13
  0001c 48 8d 0d 00 00 
        00 00            lea rcx, QWORD PTR [__NLITPACK_0.0.1]  ;C:\test\FConsole1\FConsole1\FConsole1.f90:2.13
  00023 81 4c 24 50 40 
        80 00 00         or DWORD PTR [80+rsp], 32832           ;C:\test\FConsole1\FConsole1\FConsole1.f90:2.13
  0002b 0f ae 54 24 50   ldmxcsr DWORD PTR [80+rsp]             ;C:\test\FConsole1\FConsole1\FConsole1.f90:2.13

The above was with Fortran, C++ would give similar output.

Note, the address field (00017, 0001c, ...) is the offset within the 'CODE' segment. Static data and initialized data will be located in different segments.

The base address for each segment is determined at Link time. It should be relatively easy for any programmer to write a program to obtain the base address for each segment in the Linker map file output, and then to convert the offset values to image virtual addresses, and output to a new file.

Jim Dempsey

[jimdempseyatthecove]

>>Your way also need to calculate virtual address by hand

I made a few tests, and should revise my statements.

On Windows, and (I haven't tested your version of Linux if you are using Linux), there is a "feature" introduced:

Address space layout randomization (ASLR) is a memory-protection process for operating systems (OSes) that guards against buffer-overflow attacks by randomizing the location where system executables are loaded into memory.

Here are some runs of the same program:

    program main
000000013FC71002  push        rdi  
    program main
000000013FF31002  push        rdi  
    program main
000000013FF71002  push        rdi  
Note the origin changes. Therefor, modify my suggestions to not use the address of main from the map file but rather from the start of a debug session from the location of main. In C/C++, at program start, you could print out the hex address of main, then enter that address into your program to fixup the offsets in your assembly listing (output to different file). You may need to do a similar thing with each segment.

You should be able to "automate" this to

run address fixer-upper in one CMD/terminal session, loops waiting for input
Build (with asm listing and map output)
Start debugging and get loadpoint of main,...,...
Copy you hex address(es) to paste buffer
Paste into fixer-upper (this edits relative asm listing into load point listing)
(first time you will have to open fixed file in debugger text window or other editor)
(second and later, your debugger or editor should notice file updated and should ask to reload)

Jim Dempsey

[Viet_H_Intel]

How about using -fsource-asm flag?

[jimdempseyatthecove]

Viet,

I think you are missing the point.

Lei asked:

May icc compiler generate  linked assembly code with physical address?

The answer to this is on systems that use ASLR (Windows, Linux, ???) is no, or not quite.

When you select: Output Files, Assembler Output: Machine Code with Source you get segment relative addresses combined with code/data bytes and not the virtual addresses. The Link phase then combines these into a single image. While the code segment has origin of 0 in the .exe, and formerly the image loader origin'd the in-memory image at virtual address 0, this is no longer the case. The on disk program image isn't precisely an image, instead it has a very light-weight address fixup structure that permits the load image to be jiggled (placed at a limited but arbitrary address) off of 0.

I did not what this jiggle is, but from looking at my 3 test points

000000013FC71002  push        rdi  
    program main
000000013FF31002  push        rdi  
    program main
000000013FF71002  push        rdi  

It appears that one byte, or a few bits of one byte, are manipulable at load time (the .. byte)

000000013F..1002

You might find this link interesting:

https://stackoverflow.com/questions/9560993/how-do-you-disable-aslr-address-space-layout-randomization-on-windows-7-x64

Jim Dempsey

[Viet_H_Intel]

Let us know if this is still an issue. Otherwise, we will close it.

Thanks,

[Viet_H_Intel]

We will no longer respond to this thread.  

If you require additional assistance from Intel, please start a new thread. Any further interaction in this thread will be considered community only.

Thanks,