Re: [問題]fork疑問

[descent (「雄辯是銀，沉默是金」)]

我簡化你的程式:

#include <unistd.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
  char *ptr="abcdef";
  pid_t pid;

  pid = fork();

  if (pid == 0)
  {
    printf("child ptr: %p\n", ptr);
  }
  else
  {
    printf("parent ptr: %p\n", ptr);
  }

  return 0;
}

執行結果:
parent ptr: 0x400624
child ptr: 0x400624


我在 Ubuntu 16.04.1 LTS 測試。
gcc 8.1

gcc -g -fno-pic f.c -o f


ptr 在 parent process 和 child process 都是一樣的位址。

反組譯
  char *ptr="abcdef";
  400551:       48 c7 45 f8 24 06 40    movq   $0x400624,-0x8(%rbp)

ptr 位址是 0x400624, 看以下的反組譯 0x400624, 0x61, 0x62 ~ 0x66,
就是 "abcdef"

  400620:       01 00                   add    %eax,(%rax)
  400622:       02 00                   add    (%rax),%al
  400624:       61                      (bad)
  400625:       62 63 64 65 66          (bad)  {%k5}

這整段 machine code 在 fork 之後還是長這個樣子, 所以印出來的 ptr 這個值
自然會是一樣的。

如果你想知道 fork 怎麼實作, 可以參考 Orange's 一個作業系統的實現, 裡頭有一章
在說明 fork 是怎麼實作的。

如果你不是在這環境測試, 可能無法得到這結果, 我不知道為什麼在
我的 debian, link 出來的位址和執行位址竟然不同。

※ 引述《b10007034 (Triven)》之銘言：
: https://i.imgur.com/MjKHbOu.png
: https://i.imgur.com/iUkvs5x.png
: 我照著圖中程式在Ubuntu 18.04.3執行，有幾個疑問想請教
: 為什麼child跟parent 的variable’s address一致呢？我以為copy on write會使得它們不
: 一樣
: 承上題，一樣的address不會造成它們aliasing嗎？
: 謝謝看完！

--
紙上得來終覺淺，絕知此事要躬行。

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 180.217.252.148 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1580314236.A.82A.html
推 b0920075: 0x400624那部分的位置應該只是data section存放的data
→ b0920075: ，不是 machine code...，除非你把process的數值都稱作
→ b0920075: machine code
應該是像你說的才是。
這部份一樣都會在 fork 之後被複製。

推 b0920075: 是說fork的實作應該在kernel內，linux發行版的同版本ke
→ b0920075: rnel應該要一樣吧，為啥會不一樣？
→ Lipraxde: data 當指令 dump...？
→ Lipraxde: 位置不一樣我還蠻好奇的，有圖嗎？
  char *ptr="abcdef";
    11ba:       c7 45 f4 08 20 00 00    movl   $0x2008,-0xc(%ebp)

0x2008 位址是 abcdef

    2008:       61                      popa
    2009:       62 63 64                bound  %esp,0x64(%ebx)
    200c:       65 66 00 63 68

parent ptr: 0x5656a008
child ptr: 0x5656a008

ptr 應該要是 0x2008, 但結果卻是 0x5656a008。
這是在 debian 上測試的結果。
我猜測是 loader 載入時加了一個 offset。

→ b10007034: 謝大大回覆!
推 b0920075: 這不就是PIE下的offset嗎，要加上process的base addees
→ b0920075: s才會是地址阿
我有試過 -fno-pie 也是這樣。
在 debian 使用 -m32 才可以加上 -fno-pic -fno-pie。

否則會有以下錯誤。
gcc  -g -fno-pic -fno-pie f.c -o f
/usr/bin/ld: /tmp/ccYo1k1x.o: relocation R_X86_64_32S against `.rodata' can
not be used when making a PIE object; recompile with -fPIE

看起來好像是 gcc 9 的關係, 我用 gcc5 編譯之後, 可以取得和 ubuntu 相同結果。

不知道是不是這個的關係, --enable-default-pie
https://nanxiao.me/en/gccs-enable-enable-default-pie-option-make-you-stuck-at-relocation-r_x86_64_32s-against-error/

gcc -static   -g -fno-pic -fno-pie f.c -o f
用這個也可以。

→ Lipraxde: -fno-pic 沒作用@@
※ 編輯: descent (175.98.141.254 臺灣), 01/30/2020 13:21:49
推 b0920075: 喔喔所以是gcc的關係嗎？如果是ubuntu用gcc9呢
→ Lipraxde: 直接 -no-pie，不要 f
→ descent: 感謝, 原來還有這個 option