X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id:from
         :to:cc:subject:date:message-id:reply-to;
        bh=v3m/7FL5F+JM8itpQXe+nUIi2VCLb8ih7GyCgqxfRRQ=;
        b=eA0rMExZrhqEo6v/HOe1uaq6hrfsi7FW06e5xCcNnGp6dpNfWVQcYNka86h8fsgLG1
         7BTfwLx0DAzmrZ0xskXnTmuMUiY6L+FabkdjRi00Zh/zXxkMYIVX6a/X1CIj0NEcFwCE
         Lf6BWm5Q3ZtzOoGQ+YvrLphj8UaxEsvHnWbj7GapkV1rPR++KerYE4azMhT97WEhCcbr
         9GAT1YB96/e3KzmAfIzZEXLduoLMUr1zlIExU2U3UtdWrG+rXY5J9Ob7lAK4JyLpX6kc
         PMqiDVD9CJDaM7HH2C7Mm73KRRTRvHu3U9WaIS3rv1dII+ZSJRCqhR0+Vejdfb3IaTCl
         b2LQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=v3m/7FL5F+JM8itpQXe+nUIi2VCLb8ih7GyCgqxfRRQ=;
        b=KyYy7KGARpUOwe0Mls60gGvNQ3Q+kx0PgcBf9a1AHk4HMrj2WVsqUg41EZiS06k20f
         fp35o0fOClyaABiKdl6kqQET/o/RfaopDJaNxRicQ7STj5IIeV2cShMPNgc47fwU56cg
         Y9t3EmN2xEhHgFCgRXBR2KJYyO9pH+WOpopCDCFGjDoSL6bI2GzV9eqwsqhErlQrk820
         1nfairrNmhUDQ0Hx7bE/8w1RJMdB0y5k0q1s2942p/J4qNzYNayqJgl6Itfnfimlxts3
         48FoFXwAwEY9kRoWZAL/9BFGKBo7hvZbzgkgjgnCsP7CulySYintH00KipEXDOGXEi64
         V1FA==
X-Gm-Message-State: AO0yUKU9BLYgRgAdUk/1Krayq9AKFD8SNhZ5uAzWDsLEISHWK8929M1m
	pjUSgZ101DiSVl/ab8XdlzznnB170bI=
X-Google-Smtp-Source: AK7set/u75AmriUp0i4ZgLeRiFL/vJxudhax/GMCC2UYX05w3OcaGGYPCKXEpaP4+bxdPwea5VbNkg==
X-Received: by 2002:a05:6214:1044:b0:537:7648:aa57 with SMTP id l4-20020a056214104400b005377648aa57mr2065143qvr.52.1674905339336;
        Sat, 28 Jan 2023 03:28:59 -0800 (PST)
Message-ID: <bb48230b-8090-b8d9-a108-8c90820b40e3@gmail.com>
Date: Sat, 28 Jan 2023 06:28:57 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: Linking DXE3 with libraries
To: djgpp AT delorie DOT com
References: <496da509-6d4f-88a1-e94a-6c330a915f05 AT iki DOT fi>
Content-Language: en-US
From: "Frank Sapone (emoaddict15 AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
In-Reply-To: <496da509-6d4f-88a1-e94a-6c330a915f05@iki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Good Morning Andris,

> - DXE loader has no way to found symbols of running executable (which 
> requests to load DXE) unless one tells where they are located
>
Correct, you need a DXE_EXPORT_TABLE with DXE_EXPORT(func/var) to 
resolve at run time.  See 
https://bitbucket.org/neozeed/q2dos/src/master/dos/dxe.c for an example 
if interested.
> - linking DXE directly with libraries (like libstdcxx.a or libc.a) 
> will cause duplicate copy of symbols. That is going to cause problems 
> when library have global state. I have seen similar problems, which 
> have often caused crash of program) for example in Linux, when direct 
> of indirect dependencies causes 2 different versions of shared library 
> to be loaded:
I'm not quite sure how it works exactly, but with C we just resolve 
everything like above, which seems to be the correct way.  With C++ 
things are trickier and we have to do -lstdcxx -lgcc or we get mangled 
names that can't even be exported.
> - are constructors and destructors of global objects executed, when 
> these objects belong to DXE? It seems from source code, that they 
> could. It is perhaps safer to verify that it actually works
>
I believe so, yes.
>
> I think one should avoid linking DXE with library directly, but 
> provide symbol list generated by DXE3RES (or manually) instead. 
> Exception could be if DXE module is only user of library, but program 
> itself does not use it
>
>
OK, but how do we deal with with the above C++ problem?

I will say that considering it is DOS the likliehood of someone swapping 
DXEs around is pretty slim, but I understand why you want to make it 
right.  I'd love to contribute code or even something insightful to 
these problems but I am not a compiler/compiler tools programmer.  I 
also apologize in advance for any dumb or obvious questions I may ask as 
a result of this conversation.  I just DXE3GEN like I have been for 
years and use the DXE_EXPORT... stuff to resolve at runtime.  This works 
quite well for C programs, but C++ requires additional work and it's not 
obvious what to do.

Frank