summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/105/graphic/1614348
blob: c1b608ee031fa6bb042fd79cfb9cbefb9cfb8be2 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
graphic: 0.925
semantic: 0.905
mistranslation: 0.845
other: 0.842
instruction: 0.827
device: 0.721
socket: 0.669
vnc: 0.566
network: 0.537
assembly: 0.530
boot: 0.326
KVM: 0.108

qemu-arm core dumped for no entry symbol programe

Hi qemu developers,

Environment:
* Fedora 24 x86_64
* qemu-arm version 2.6.92, Copyright (c) 2003-2008 Fabrice Bellard
* arm-linux-gnu-gcc 6.1.1 20160621 (Red Hat Cross 6.1.1-2) (GCC) target: arm-linux-gnueabi
* glibc-arm-linux-gnu-devel-2.23

very simple hello.c:

#include <stdio.h>

int main(int argc, char *argv[]) 
{
    printf("Hello World\n");

    return 0;
}

arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib -lc

/usr/bin/arm-linux-gnu-ld: Warning: Cannot find entry symbol _start; defaulting to 00000000000101fc

qemu-arm -L /usr/arm-linux-gnu ./a.out

Hello World
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
Illegal instruction

But provided entry symbol: 

arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib /usr/arm-linux-gnu/lib/crt1.o /usr/arm-linux-gnu/lib/crti.o /usr/arm-linux-gnu/lib/crtn.o -lc

qemu-arm -L /usr/arm-linux-gnu ./a.out is able to work happily!

Regards,
Leslie Zhai

file a.out

a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=6a86f764c1200a41253e1bc80d3155a295b87818, not stripped

Why do you think this is a bug in QEMU? This program crashes on exit if you run it on real arm hardware. This is unsurprising as you have told the compiler to build it with no C runtime. The program thus starts at the beginning of 'main', and when it hits the return at the end there is nowhere for it to return to and it crashes. If you link the program with the C runtime the way you are expected to, then the runtime gets control at the start of execution and provides a place for main() to return to. If you choose not to link against the C runtime then it is your responsibility to provide an alternate runtime (including defining an entry point) which implements the semantics that the main() function expects.