Tôi có thể trộn tay-eabi với cánh tay không?

Question

Tôi có một sản phẩm có bộ tải khởi động và ứng dụng được biên dịch bằng trình biên dịch (gnuarm GCC 4.1.1) tạo ra "arm-elf".

Trình tải khởi động và ứng dụng được tách biệt trong các vùng bộ nhớ FLASH khác nhau trong tập lệnh trình liên kết.

Ứng dụng có tính năng cho phép nó gọi bộ nạp khởi động (dưới dạng c chức năng đơn giản với 2 tham số).

Tôi cần có khả năng nâng cấp các sản phẩm hiện có trên khắp thế giới và tôi có thể thực hiện việc này một cách an toàn bằng cách sử dụng cùng một trình biên dịch.

Bây giờ tôi muốn có thể biên dịch ứng dụng sản phẩm này bằng cách sử dụng phiên bản GCC mới có kết quả là arm-eabi.

Mọi thứ sẽ ổn cho các sản phẩm mới, nơi cả ứng dụng và bộ tải khởi động được biên dịch bằng cùng một chuỗi công cụ, nhưng điều gì sẽ xảy ra với các sản phẩm hiện có? Nếu tôi flash một ứng dụng mới, được biên dịch với GCC 4.6.x và arm-no-eabi, ứng dụng của tôi vẫn có thể gọi chức năng bộ nạp khởi động từ bộ nạp khởi động cũ của arm-elf không?

---

Hơn nữa, không liên quan trực tiếp đến câu hỏi trên, tôi có thể trộn các tệp đối tượng được biên dịch với arm-elf vào nhị phân được biên dịch bằng arm-eabi không?

---

EDIT:

tôi nghĩ là tốt để làm cho rõ ràng tôi đang xây dựng cho một ARM7 kim loại trần, nếu nó làm cho bất kỳ sự khác biệt ...

Answer 1

số Một ABI là sự kỳ diệu mà làm cho tương thích nhị phân. Giao diện nhị phân ứng dụng xác định các quy ước khác nhau về cách giao tiếp với các thư viện/ứng dụng khác. Ví dụ, một ABI sẽ định nghĩa quy ước gọi, điều này làm cho các giả định ngầm định về những thứ như các thanh ghi nào được sử dụng để chuyển các đối số tới các hàm C và cách xử lý các đối số dư thừa.

Tôi không biết sự khác biệt chính xác giữa EABI và ABI, nhưng bạn có thể tìm thấy một số người trong số họ bằng cách đọc EABI. Debian's page đề cập đến quy ước syscall là khác nhau, cùng với một số thay đổi căn chỉnh.

Với những điều trên, tất nhiên, bạn không thể kết hợp các đối tượng cánh tay-elf và arm-eabi.

Câu trả lời ở trên được đưa ra dựa trên giả định rằng bạn nói chuyện với mã bộ nạp khởi động trong ứng dụng chính của bạn. Cho rằng giao diện có thể rất đơn giản (chỉ cần một cuộc gọi hàm với hai tham số), có thể nó có thể hoạt động. Nó sẽ là một thử nghiệm thú vị để thử. Tuy nhiên, nó không được ** đảm bảo ** để hoạt động.

Hãy nhớ rằng bạn không phải sử dụng EABI. Bạn có thể tạo ra một chuỗi công cụ arm-elf với gcc 4.6 cũng như với các phiên bản cũ hơn. Vì bạn đang sử dụng một chuỗi công cụ nhị phân trên các cửa sổ, bạn có thể có nhiều thách thức hơn. Tôi muốn đề nghị điều tra crosstool-ng, hoạt động khá tốt trên Linux và có thể hoạt động tốt trên cygwin để xây dựng chuỗi công cụ thích hợp.

Answer 2

Luôn có tùy chọn gọi hàm khởi động trong lắp ráp nội tuyến, trong trường hợp này bạn có thể tuân theo bất kỳ tiêu chuẩn gọi nào bạn cần :).

Tuy nhiên, bên cạnh những tính di động phát hành nó giới thiệu, phương pháp này cũng sẽ làm cho hai giả định về bootloader và ứng dụng của bạn:

• bạn có thể phát hiện trong ứng dụng của bạn mà một thiết bị đặc biệt có một bộ nạp khởi động xây dựng với bạn chuỗi công cụ không phải EABI, vì bạn chỉ có thể gọi trình khởi động kiểu cũ hơn bằng cách sử dụng mã assembly.
• hai tham số bạn đã đề cập được sử dụng làm dữ liệu nguyên thủy bởi bộ nạp khởi động của bạn. Ví dụ, trình tải khởi động có sử dụng chúng như các con trỏ tới các cấu trúc hay không, bạn có thể phải đối mặt với các vấn đề với căn chỉnh không đúng, phần đệm và vv.

Answer 3

I Hãy suy nghĩ rằng điều này sẽ ổn. Tôi đã làm một di chuyển một cái gì đó như thế này bản thân mình, từ những gì tôi nhớ tôi chỉ chạy vào một vấn đề để làm với xử lý phân chia.

This is the best info I can find about the differences, đề xuất rằng nếu bạn không có vấn đề về căn chỉnh cấu trúc, bạn có thể OK.