2011-08-04 29 views
7

Đây là gần Using GCC to produce readable assembly?, nhưng ngữ cảnh của tôi ở đây là avr-gcc (và tương ứng, avr-objdump) cho Atmel (mặc dù, tôi đoán nó sẽ áp dụng trên bảng GCC).GCC/objdump: Tạo ra lắp ráp compilable/buildable (xen kẽ với C/C++)?

Vấn đề là, tôi có một dự án gồm nhiều tệp .c và .cpp; cuối cùng được biên dịch thành một tệp thực thi, có cùng tên với tệp .cpp 'chính'. Trong quá trình này, tôi có thể có được danh sách lắp ráp theo hai cách:

  • tôi có thể hướng dẫn gcc phát ra lắp ráp niêm yết nguồn (xem Linux Assembly and Disassembly an Introduction) sử dụng -S chuyển đổi; trong trường hợp này, tôi nhận được một tập tin, với nội dung như sau:
     
    ... 
    loop: 
        push r14 
        push r15 
        push r16 
        push r17 
        push r28 
        push r29 
    /* prologue: function / 
    / frame size = 0 */ 
        ldi r24,lo8(13) 
        ldi r22,lo8(1) 
        call digitalWrite 
        rjmp .L2 
    .L3: 
        ldi r24,lo8(MyObj) 
        ldi r25,hi8(MyObj) 
        call _ZN16MYOBJ7connectEv 
    .L2: 
        ldi r24,lo8(MyObj) 
        ldi r25,hi8(MyObj) 
        call _ZN16MYOBJ11isConnectedEv 
    ... 
    

(đã không thử nó chưa, nhưng tôi đoán mã này là compilable/thể xây dựng ....)

  • Tôi có thể kiểm tra thực thi cuối cùng và hướng dẫn, objdump để phát ra nguồn danh sách lắp ráp bằng cách sử dụng công tắc -S; trong trường hợp này, tôi nhận được một tập tin, với nội dung như sau:
     
    ... 
    0000066a <init>: 
    void init() 
    { 
         // this needs to be called before setup() or some functions won't 
         // work there 
         sei(); 
        66a:  78 94   sei 
        66c:  83 b7   in  r24, 0x33  ; 51 
        66e:  84 60   ori  r24, 0x04  ; 4 
        670:  83 bf   out  0x33, r24  ; 51 
    ... 
    000006be <loop>: 
        6be:  ef 92   push r14 
        6c0:  ff 92   push r15 
        6c2:  0f 93   push r16 
        6c4:  1f 93   push r17 
        6c6:  cf 93   push r28 
        6c8:  df 93   push r29 
        6ca:  8d e0   ldi  r24, 0x0D  ; 13 
        6cc:  61 e0   ldi  r22, 0x01  ; 1 
        6ce:  0e 94 23 02  call 0x446 ; 0x446 
        6d2:  04 c0   rjmp .+8    ; 0x6dc 
        6d4:  8d ef   ldi  r24, 0xFD  ; 253 
        6d6:  94 e0   ldi  r25, 0x04  ; 4 
        6d8:  0e 94 25 06  call 0xc4a ; 0xc4a <_ZN16MYOBJ7connectEv> 
        6dc:  8d ef   ldi  r24, 0xFD  ; 253 
        6de:  94 e0   ldi  r25, 0x04  ; 4 
        6e0:  0e 94 21 06  call 0xc42 ; 0xc42 <_ZN16MYOBJ11isConnectedEv> 
    ... 
    

(tôi đã cố gắng xây dựng mã này, và nó đã thất bại - nó đọc 'số dòng' như nhãn)

Rõ ràng, cả hai danh sách (đối với hàm loop, ít nhất) đại diện cho cùng một mã assembly; trừ:

  • Các gcc một (nên) biên dịch - các objdump một trong những hiện không
  • Các objdump một chứa danh sách của tất cả các chức năng gọi, mà có thể được định nghĩa trong các tập tin khác với 'thầy' (ví dụ, digitalWrite) - các gcc một trong những hiện không
  • các objdump một chứa gốc C/C++ dòng nguồn 'xen kẽ' với lắp ráp (nhưng chỉ thỉnh thoảng mới, và dường như chỉ dành cho C files) - các gcc một trong những hiện không

Vì vậy, là có một cách để có được một danh sách lắp ráp đó sẽ là 'compilable', tuy nhiên với tất cả các chức năng trong liên kết, và nơi nguồn C/C++ là (có thể, nơi thích hợp) xen kẽ như ý kiến ​​(để họ không can thiệp với biên dịch của tập tin lắp ráp)? (viết ngắn một trình phân tích cú pháp cho đầu ra của objdump, nghĩa là :))

Trả lời

1

Thêm tùy chọn -fverbose-asm vào dòng lệnh gcc của bạn trên đó. (Đây là tài liệu hướng dẫn gcc, nhưng nó được ghi lại dưới 'Tùy chọn Mã nguồn')

+0

Rất cám ơn vì điều đó, @ Spudd86 - vừa thử tùy chọn '-fverbose-asm'; tuy nhiên, nó không "bao gồm các phụ thuộc", và cũng không giữ nguyên dòng nguồn C/C++ nguyên văn ... Nó tạo ra một danh sách "_options passed_" và nó sẽ bắt đầu chú ý một số biến: 'lds r24, MyObj \t; MyObj._isConnected, MyObj._isConnected' - nhưng tôi đoán tôi quan tâm nhiều hơn đến việc bắt đầu các hàm bằng cách nào đó bị giới hạn ... Cảm ơn lần nữa - chúc mừng! – sdaau

1

"Phụ thuộc" mà bạn nói thường đến từ thư viện hoặc tệp đối tượng riêng biệt, vì vậy chúng không có nguồn - chúng ' chỉ được liên kết dưới dạng mã nhị phân vào tệp thực thi cuối cùng. Vì mã như vậy không được truyền qua bộ lắp ráp, bạn sẽ phải giải mã nó bằng các cách khác - ví dụ: sử dụng objdump.

Có thể bạn nên cho chúng tôi biết bạn thực sự muốn đạt được vì tôi không thấy nhiều điểm trong một bài tập như vậy một mình.

+0

Xin chào @Igor Skochinsky, cảm ơn vì đã bình luận! Bạn là đúng - nhưng trong trường hợp cụ thể của mã AVR, thường là rất nhiều các tập tin đối tượng thực sự đến từ các tập tin nguồn. Những gì tôi đã hy vọng, là cuối cùng tạo ra một tập tin "hợp nhất", mà tôi có thể sử dụng để tạo ra ít hơn cùng một tệp thực thi ELF như dự án - sau đó tôi dự định sử dụng danh sách assembly này trong avr-gdb để gỡ lỗi (như hiện tại, tôi dường như không thể đặt gdb lên, do đó, nó nắm bắt các dòng nguồn chính xác trong quá trình gỡ lỗi). Cảm ơn một lần nữa - chúc mừng! – sdaau

+0

Tôi muốn nói việc sửa lỗi với gdb nên dễ dàng hơn (hy vọng) và, cuối cùng, cách tiếp cận chính xác hơn. –

1

Điều tốt nhất tôi có thể nhận được là sử dụng -Wa,-ahl=outfile.s thay vì -S. Nó không phải là mã compilable mặc dù, nhưng một tập tin danh sách cho các mục đích chẩn đoán; tệp đối tượng được biên dịch được phát ra như bình thường.

+0

Cảm ơn rất nhiều vì điều đó @Anonymous Coward - rất tốt khi biết tùy chọn đó! Chúc mừng! – sdaau

Các vấn đề liên quan