Project

General

Profile

Bug #10089

[x86] Некорректные трассы для тестов "bubble_sort" и "euclid"

Added by Alexander Protsenko 8 months ago. Updated 8 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Samples
Target version:
Start date:
02/03/2020
Due date:
% Done:

0%

Estimated time:
Detected in build:
master
Platform:
Published in build:

Description

Сравнил логи трасс:
https://forge.ispras.ru/jenkins/job/MicroTESK/ws/build/test/x86gnu/euclid/euclid_0000-qemu.log
https://forge.ispras.ru/jenkins/job/MicroTESK/ws/build/test/x86gnu/bubble_sort/bubble_sort_0000-qemu.log

Есть гипотеза, о содержании ошибки в данных трассах.
Такой тест "bubble_sort" не должен давать трассу в ~11 000 строк.

    .code16

    .text
    .globl _start
_start:

    mov $200, %AX

success:
    mov $1, %AX
    # system call number (sys_exit)
    int $128
error:
    # call kernel
    .word 0xaa55

При этом логи практически одинаковы для теста "euclid" и для некорректного на данный момента теста "bubble_sort".
Файлы добавил в задачу.
Необходимо проверить (и если надо исправить) проблему с логами.


Files

bubble_sort_0000-qemu.log.txt (579 KB) bubble_sort_0000-qemu.log.txt Alexander Protsenko, 02/03/2020 12:21 PM
euclid_0000-qemu.log.txt (584 KB) euclid_0000-qemu.log.txt Alexander Protsenko, 02/03/2020 12:21 PM

Associated revisions

Revision 889d6f90 (diff)
Added by Sergey Smolov 8 months ago

fix wrong traces for x86 programs are compiled by GNU asm (#10089)

Basic template has been restored in such a way that test programs it is capable to generate will be similar to runnable-on-QEMU examples from GitHub (https://github.com/cirosantilli/x86-bare-metal-examples/tree/bc74cd1819ffbd8beeccabeea0b82f9ba7014f74/no-linker-script)

Signed-off-by: Sergey Smolov <>

History

#1

Updated by Sergey Smolov 8 months ago

  • Detected in build changed from svn to master
  • Status changed from New to Resolved
  • Category set to Samples

The main error that has been detected here is an absence of test program in QEMU4V log. It is fixed in 889d6f90
As for long QEMU4V logs - it is ok, because QEMU4V is unable to stop simulation on some "terminate" instruction. Instead, it continues the emulation. In our test system QEMU4V is just stopped by timeout (1 sec). Also for x86 architecture QEMU4V starts the emulation from embedded boot, that also makes logs longer.

Also available in: Atom PDF