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=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=B9iQuxNB0bEKuLC3b+VGMjf8gPdPBHK40CeVR/FwEXI=;
        b=KS3iGrrK2doeTSEyptdw9xD96pAs1uwQZoRjM0Rn0qFasEY3yM/TKnMDd3kOMH0acs
         a9QpzckMeYUbeTrZJSxoJtfO9f8wY2akSEJV4nn61VWLkLbPQWL5nxBTc//J9htYMFHr
         zLomOXxq/ygBBrv1TLsqLU19lqeh0+7wM2NrpLi3gUt0JISGZF3b5xrtF5S91FpKicE1
         uCRZOqERJVp8H+YBZSZNsz5rPjcdOlGSuPAJ41x3lksUHiw8c7G0XFV9J62BqESh9q8q
         4KZ/fbYnhPJbHaETp+orWMXGZw3e3hEGXCaFGbVsTl16b/Liri742lgbNOTqazo0jFAR
         xElg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=B9iQuxNB0bEKuLC3b+VGMjf8gPdPBHK40CeVR/FwEXI=;
        b=L7TUFXYuFEGAeUyxXT6dhV+oZ0k31INHhlYrTbF+98qU4vECgEJGh+X6pQSw3eBMoF
         h0p4uCcX+2VZUQb1x/7hsD64RCx30SXQISb27jMXdSyGljt8jgtAbDtQ4K1KYCYiuU3Z
         YnJQ5rafvkNQRRgP1/TZzQd9YLMuPTY/I1lG7Sj3ZIVCAFsMG606On34G/RBKkBDaJlT
         vIjJfXUhMWwYcR8lb+OFvo6gZa5upIK/43HHQ7NqCtP4lC1q+vEe07UdYhzAp9ix7SBd
         ZTxlk2PFHEJxqfRdJ+dYxRNSKs2eUl3XdWI+pnvZ1gCQqkSvMbPpNY4QozSymJOTEwcB
         qg6A==
X-Gm-Message-State: AO0yUKXF+nSQaa0nG32zysIII6IYsHE7k2hJqNZ5en/auexg9rGBcTWp
	TOquMGHYLmGse9RghU8ZYWTvEiNUk/6ttkszz8/CM1dB
X-Google-Smtp-Source: AK7set9PGBmdMTVICa5ZG2RR+QLBwjz7EwPPjRHkarEOco7W0dGjx/O9sJ5XgW0frfxmZyVdOgXh098K+PeykWryIBc=
X-Received: by 2002:adf:ce01:0:b0:2c4:4c52:f604 with SMTP id
 p1-20020adfce01000000b002c44c52f604mr231801wrn.547.1676550576462; Thu, 16 Feb
 2023 04:29:36 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <CAA2C=vA8tH7vJ24kaNk3x8txvROon_K8UEdMJh_9b78utm1SAw@mail.gmail.com>
References: <CAA2C=vDf3MRSeBV_30REYLgJRUM_3uOzrej+_tN0HXXTZAXvvg AT mail DOT gmail DOT com>
 <CAA2C=vASQ0KY_jA05tUWpRHTocGtDKgn=KAU00JOezmbRu827Q AT mail DOT gmail DOT com> <CAA2C=vA8tH7vJ24kaNk3x8txvROon_K8UEdMJh_9b78utm1SAw AT mail DOT gmail DOT com>
From: "Ozkan Sezer (sezeroz AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Date: Thu, 16 Feb 2023 15:29:35 +0300
Message-ID: <CAA2C=vDcaq72jxb4AmaUgUs1ua0pxGWXTAg82mbHxHpHh1p4xQ@mail.gmail.com>
Subject: Re: dxe: page fault when derefencing an exported pointer variable
To: djgpp AT delorie DOT com
Cc: Daniel Borca <dborca AT yahoo DOT com>
Content-Type: text/plain; charset="UTF-8"
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

On 2/16/23, Ozkan Sezer <sezeroz AT gmail DOT com> wrote:
>>> The 'normal' vars don't seem to have a problem, but dereferencing
>>> that particular pointer results in a page fault:
>
> Well, I was very very wrong:
>
> I added some debug printf() statements to a simple program, so that
> it prints the values of certain variables exported by the library :
>
> UBYTE md_volume      : 233 (0xe9) --- should have been 128
> UBYTE md_musicvolume : 233 (0xe9) --- should have been 128
> UBYTE md_sndfxvolume : 233 (0xe9) --- should have been 128
> UBYTE md_reverb      : 233 (0xe9) --- should have been 0
> UBYTE md_pansep      : 233 (0xe9) --- should have been 128
> UWORD md_mixfreq     : 44100
> UWORD md_mode        : 63977 (0xf9e9) --- should have been 0x110F
> UWORD md_device      : 9705  (0x25e9) --- should have been ???
> MDRIVER* md_driver   : 0xcea27e9
> CHAR* md_driver->Name: [crash...]
>
> Note that all of those values have 0xe9 - except for md_mixfreq to
> which I do assign 44100.  0xe9 (i.e.: jmp) seems to be coming from
> dlstatbind():
> https://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/dxe/dxe3stat.c?rev=1.1
>
> Looks like exported variables support in import libraries is very
> much broken?

Daniel Borce has shed some light:

On 2/16/23, Daniel Borca <dborca AT yahoo DOT com> wrote:
>
> I believe this is because of how variables are exported (as opposed to
> functions).
>
> Things are quite foggy after all those years, but for COFF, you are actually
> getting a _pointer_ to a variable. That is, in your case a _pointer_ to the
> desired pointer (that's why having a getter for the pointer solves it). I
> know this is *not* how it works when you are compiling statically, but it is
> a limitation of the executable format. I also think this limitation applies
> to the original DXE (as designed by Charles W Sandmann) not only for my
> DXE3. BTW, the COFF used by DJGPP is not even Windows COFF.
>
> TL;DR: you have to dereference that pointer twice. I am not sure it can be
> handled transparently as long as DJGPP was COFF-based.
>
> That's why I "invented" DJELF back then. The ELF executable format has a
> special kind of relocation (perhaps it was called R_<arch>_COPY or something
> like that) which would solve this issue magically, but then you are
> restricted to ELF.
>
> -dborca

Thanks Daniel.