1

I got some source code in plain C. It is built to run on ARM with a cross-compiler on Windows.

Now I want to do some white-box unit testing of the code. And I don't want to run the test on an ARM board because it may not be very efficient.

Since the C source code is instruction set independent, and I just want to verify the software logic at the C-level, I am wondering if it is possible to build the C source code to run on x86. It makes debugging and inspection much easier.

Or is there some proper way to do white-box testing of C code written for ARM?

Thanks!

BTW, I have read the thread: How does native android code written for ARM run on x86?

It seems not to be what I need.

ADD 1 - 10:42 PM 7/18/2021

The physical ARM hardware that the code targets may not be ready yet. So I want to verify the software logic at a very early phase. Based on John Bollinger's answer, I am thinking about another option: Just build the binary as usual for ARM. Then use QEMU to find a compatible ARM cpu to run the code. The code is assured not to touch any special hardware IO. So a compatible cpu should be enough to run all the code I think. If this is possible, I think I need to find a way to let QEMU load my binary on a piece of emulated bare-metal. And to get some output, I need to at least write a serial port driver to bridge my binary to the serial port.

ADD 2 - 8:55 AM 7/19/2021

Some more background, the C code is targeting ARMv8 ISA. And the code manipulates some hardware IPs which are not ready yet. I am planning to create a software HAL for those IPs and verify the C code over the HAL. If the HAL is good enough, everything can be purely software and I guess the only missing part is a ARMv8 compatible CPU, which I believe QEMU can provide.

ADD 3 - 11:30 PM 7/19/2021

Just found this link. It seems QEMU user mode emulation can be leveraged to run ARM binaries directly on a x86 Linux. Will try it and get back later.

ADD 4 - 11:42 AM 7/29/2021

An some useful links:

Override a function call in C

__attribute__((weak)) and static libraries

What are weak functions and what are their uses? I am using a stm32f429 micro controller

Why the weak symbol defined in the same .a file but different .o file is not used as fall back?

smwikipedia
  • 61,609
  • 92
  • 309
  • 482
  • It depends. If the code was written in a portable way, it should run without problems on both big endian (ARM) and little endian (x86) architectures. – qrdl Jul 18 '21 at 13:56
  • 1
    @qrdl ARM is bi-endian, and most modern ARM systems run in little endian – phuclv Jul 18 '21 at 14:48
  • qemu or similar is the only on x86 option. if the hardware is not ready yet then I assume there was no reference platform that the hardware was designed from that you can run on? – old_timer Jul 18 '21 at 16:34
  • @old_timer Thanks for the comment. I just append *ADD 2* for more background info. – smwikipedia Jul 19 '21 at 01:01

2 Answers2

2

Now I want to do some white-box unit testing of the code. And I don't want to run the test on an ARM board because it may not be very efficient.

What does efficiency have to do with it if you cannot be sure that your test results are representative of the real target platform?

Since the C source code is instruction set independent,

C programs vary widely in how portable they are. This tends to be less related to CPU instruction set than to target machine and implementation details such as data type sizes, word endianness, memory size, and floating-point implementation, and implementation-defined and undefined program behaviors.

It is not at all safe to assume that just because the program is written in C, that it can be successfully built for a different target machine than it was developed for, or that if it is built for a different target, that its behavior there is the same.

I am wondering if it is possible to build the C source code to run on x86. It makes debugging and inspection much easier.

It is probably possible to build the program. There are several good C compilers for various x86 and x86_64 platforms, and if your C code conforms to one of the language specifications then those compilers should accept it. Whether the behavior of the result is representative of the behavior on ARM is a different question, however (see above).

It may nevertheless be a worthwhile exercise to port the program to another platform, such as x86 or x86_64 Windows. Such an exercise would be likely to unmask some bugs. But this would be a project in its own right, and I doubt that it would be worth the effort if there is no intention to run the program on the new platform other than for testing purposes.

Or is there some proper way to do white-box testing of C code written for ARM?

I don't know what proper means to you, but there is no substitute for testing on the target hardware that you ultimately want to support. You might find it useful to perform initial testing on emulated hardware, however, instead of on a physical ARM device.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • Thanks for the answer. I just updated my question with *ADD 1*. – smwikipedia Jul 18 '21 at 14:42
  • Ok, @smwikipedia, but I don't see how that addendum calls for a different answer. And if it did, then with your rep, you should already be aware that around here we look poorly on making substantive modifications to a question after it already has answers. – John Bollinger Jul 18 '21 at 14:52
  • Sorry if that complicates things. I am just looking for a solution to this problem. Your answer inspired me to think another way. And to keep the question history, I use the *ADD 1* title. – smwikipedia Jul 18 '21 at 14:55
  • 1
    Well if debugging on emulated hardware is a helpful new idea then it is my pleasure to have been of service. – John Bollinger Jul 18 '21 at 14:58
1

If you were writing ARM code for a windows desktop application there would be no difference for the most part and the code would just compile and run. My guess is you are developing for some device that does some specific task.

I do this for a lot of my embedded ARM code. Typically the core algorithms work just fine when built on x86 but the whole application does not. The problems come in with the hardware other than the CPU. For example I might be using a LCD display, some sensors, and Free RTOS on the ARM project but the code that runs on Windows does not have any of these. What I do is extract important pieces of C/C++ code and write a test framework around it. In the real ARM code the device is reading values from a sensor and doing something with it. In the test code that runs on a desktop the code reads from a data file with fake sensor values and writes its output to a datafile that can be analyzed. This way I can have white box tests for the most complicated code.

May I ask, roughly what does this code do? An ARM processor with no peripherals would be kind of useless. Typically we use the processor to interact with some other hardware like a screen, some buttons, or Bluetooth. It's those interactions that are going to be the most problematic.

Marc
  • 1,159
  • 17
  • 31