Почему _exit (0) (выход из syscall) не позволяет мне получать содержимое stdout?
У меня есть программа сборки Linux x86-32 GAS, которая завершается следующим образом:
movl $1, %eax
movl $0, %ebx # argument for _exit
int $0x80
Когда я выхожу так, программа работает как обычно, но если я пытаюсь прочитать вывод stdout, я ничего не получаю (т.е. используя less или wc).
Я попытался скомпилировать минимальную C-программу и сравнить результаты strace. Единственное различие, которое я обнаружил, заключалось в том, что GCC сделал программу C (int main() { printf("donkey\n"); }
) безоговорочно выход сexit_group(0)
в выводе strace.
Я попытался изменить мою программу ASM, чтобы выйти сcall exit
вместо сырого системного вызова. Stdout теперь можно было читать как обычно.
Прецедент
.data
douout: .string "monkey\n"
.text
.globl main
main:
pushl $douout
call printf
# Exit
movl $1, %eax
movl $0, %ebx
int $0x80
Скомпилируйте и запустите:
$ yasm -g dwarf2 -f elf -p gas t.asm && gcc -g -melf_i386 -o t t.o && ./t | wc -c
0
Ожидаемое:
7
РЕДАКТИРОВАТЬ:
Я пытался позвонить обоимtcflush
а такжеfflush
и у меня все еще есть проблема. С участиемfflush
Я даже получил Segfault.
0xb7e9e7c9 in _IO_fflush (fp=0x804a018) at iofflush.c:42
42 iofflush.c: No such file or directory.
in iofflush.c
(gdb) bt
#0 0xb7e9e7c9 in _IO_fflush (fp=0x804a018) at iofflush.c:42
#1 0x08048434 in main () at t.asm:12
(gdb) frame 1
#1 0x08048434 in main () at t.asm:12
12 call fflush
(gdb) list
7
8 pushl $douout
9 call printf
10 # Exit
11 movl $0, %eax
12 call fflush
13 movl $1, %eax
14 movl $0, %ebx
15 int $0x80
EDIT2:
Ладно, теперь все работает. Я использовал неправильное соглашение о вызовах, которое я скопировал отсюда:Printf без новой строки в сборке
Аргумент заfflush
должно быть в стеке, как обычно.
$ cat t.asm
.data
douout: .string "monkey\n"
.text
.globl main
main:
pushl $douout
call printf
# Exit
pushl $0
call fflush
movl $1, %eax
movl $0, %ebx
int $0x80
$ yasm -g dwarf2 -f elf -p gas t.asm && gcc -g -melf_i386 -o t t.o && ./t | wc -c
7
$
Спасибо всем, особенно NOS.