From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <qcloud1014@gmail.com>
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [IPv6:2a00:1450:4864:20::133])
 by sourceware.org (Postfix) with ESMTPS id 33DA6388C022
 for <libc-help@sourceware.org>; Tue,  5 Jan 2021 03:25:17 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 33DA6388C022
Received: by mail-lf1-x133.google.com with SMTP id m25so69358659lfc.11
 for <libc-help@sourceware.org>; Mon, 04 Jan 2021 19:25:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=XVq/CzOJypCGg8ev1uz0y9YMIOkud6MsbPieY2XWYcA=;
 b=eT4OxBuysx7sCdM0upERKXfoZupjVQOSJugzRYG3UuFberq4s5Ukzf2QL6tbp1kO5/
 2iKPLlxzqXzBp+sWghmuF2wDrKkMoimRd59byLHY6VI9uAo2WCMHCP8g3/3+8Bo5jg04
 YVWAIdM2aHsI5jSP4WP/8LOc0w3e5jRXdKgPXB1o+rKFsjl5GoomqeAmhhnbtphUyHxS
 WusjRRD3IxFl482cp0G+fuCdrEWkcvVtlCEhpZYmcxYDr9Iz/XvT95HpuhwYpZdy6rfB
 BRXtk49sKthkG1puI1cvyDjclKvOzJa56oOGhM1YHuTvqwCActhoyeVN894DXB4FDdgI
 ZsGg==
X-Gm-Message-State: AOAM5322VjAmZN8pyuNjh0JhGV48oiIfJ0wDzz5jo8fDYxW1b/d7Z8E3
 Z9OPKHrIRWuLBcll6jdR2dWJtmYkUba7J26b0+0atfec
X-Google-Smtp-Source: ABdhPJzXY4au3TYeIgMf9JQQj3rXMoYCfAV13issYH++5YzKmy/W7XFMUI/fBZyIvKcJ57DEeu3T9kb2euRxbqKIY4c=
X-Received: by 2002:a19:85c1:: with SMTP id
 h184mr31985888lfd.243.1609817115790; 
 Mon, 04 Jan 2021 19:25:15 -0800 (PST)
MIME-Version: 1.0
From: Fengkai Sun <qcloud1014@gmail.com>
Date: Tue, 5 Jan 2021 11:25:04 +0800
Message-ID: <CAF6YOcO1WHNrhrmzfsHiNzRNdc7soMSUpQQd0jYXE8mLU_vH9Q@mail.gmail.com>
Subject: Is writing a dynamic linker/loader to load glibc a bad idea?
To: libc-help@sourceware.org
X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT,
 FREEMAIL_FROM, HTML_MESSAGE, KAM_STOCKGEN, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,
 SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
X-BeenThere: libc-help@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-help mailing list <libc-help.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-help>,
 <mailto:libc-help-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-help/>
List-Help: <mailto:libc-help-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-help>,
 <mailto:libc-help-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2021 03:25:18 -0000

Hi list,

Sorry in advance if this question is a bit unclear and confusing.

Recently I want to implement an ld.so myself, that is, a DSO that allows me
to load other DSOs into memory.

I've tried my best to finish all the steps that I discovered: loading
PT_LOAD segments with mmap, loading dependencies, relocating, and calling
DT_INIT and DT_INITARRAY in the right order.

It works all right when the DSO is simple, e.g. using a few printfs and
other libc functions. But it fails when I'm using some(not all) DSOs in the
real world.

Through some debugging, I found that the problem might be caused by some
initialized variables. So I tried this when doing relocation:

IF FIND_SYMBOL_IN_LIBC:
        void* handle = dlopen("libc.so.6", RTLD_LAZY);
        void* symbol_address = dlsym(handle, symbol_name);
        if(symbol_address)
                return symbol_address;

And it works fine.

So I think the bug is obvious: I missed out some parts when trying to load
libc as a dependency. But libc is huge, I'm not sure if it is a great idea
to do that all by myself -- currently I cannot find what is overlooked.

Any intuitive advice will be greatly appreciated.

Best,
Fengkai