X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient: djgpp-workers AT delorie DOT com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=pTn2/R/7cQJnU3fha1nzvQWrDMkvBvKdploJYc9g2O0=;
        b=NLLYesoSpf5JMIV0BUZwIK6zULaB8kVjF8kg5nv/zhrz5/Ri9XG66TC3KupgSslCYM
         pRe/nDrAR+cIHihn9D6pKTt03sJuuy8tpPZbRpeIvRDqRUEYuzT3G0eiFNe5ALlRNe7J
         KR2eu0YQDYUal4He2O5VIloVkBSAoY5uiewJA=
MIME-Version: 1.0
In-Reply-To: <83zkjwcknb.fsf@gnu.org>
References: <CAA2C=vCTyDxWBgYzoBB31=hoOBHJhL+famn_6XL2eYb3a_3egA AT mail DOT gmail DOT com>
	<83zkjwcknb DOT fsf AT gnu DOT org>
Date: Sat, 30 Jul 2011 11:04:49 +0300
Message-ID: <CAA2C=vDN6vmzujDe6QngP-GTJSEwo1WO3jCvciuh3NUB+Qjd9A@mail.gmail.com>
Subject: Re: [PATCH] allow 64 bit host tools when cross compiling
From: Ozkan Sezer <sezeroz AT gmail DOT com>
To: djgpp-workers AT delorie DOT com
Content-Type: text/plain; charset=ISO-8859-1
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Sat, Jul 30, 2011 at 10:06 AM, Eli Zaretskii <eliz AT gnu DOT org> wrote:
>> Date: Fri, 29 Jul 2011 23:01:07 +0300
>> From: Ozkan Sezer <sezeroz AT gmail DOT com>
>>
>> On Fri, Jul 29, 2011 at 6:32 PM, Ozkan Sezer <sezeroz AT gmail DOT com> wrote:
>> > Hi all:
>> >
>> > dxegen segfaults when built as a 64 bit host tool in
>> > dxe3gen.c:553 (write_dxe) most probably due to "long"
>> > data type usage at many places (such as coff.h)
>
> Can you provide more details about the context?  Are you trying to run
> dxegen _natively_ (as opposed to as a cross-compilation tool) on a
> x86_64 platform?

Yes

>   IOW, what is the purpose of this compilation?
>


To compile the djgpp runtime library


>> OK, here is a patch that seems to work for me (see attached 64.patch)
>
> If this is just a replacement of integer types, then it's a largely
> mechanical patch.
>
> It is mostly okay, but I don't understand why you went so far and
> deep, and changed also the types that don't need to be changed at all.
> For example, neither `short' nor `int' have different size on any
> known machine that can be ever supported by DJGPP, so why change them
> at all?

For consistency,

>    IOW, I would only change `long' to `int', and that's it.  No
> need for stdint.h and intNN_t stuff.  Would that be enough?
>


EDIT:
Not tested, but should be enough.  (There might be places where the
compiler may behave overzealous about long vs. int pointers, though:
int32_t is `long' in djgpp so using it won't cause any extra trouble
but using `int' _may_: not tested myself but just making a note.)


>> -        fwrite(&relocs[i].r_vaddr, 1, sizeof(long), outf);
>> +        fwrite(&relocs[i].r_vaddr, 1, sizeof(int32_t), outf);
>
> This (and other similar) issue are better solved by using the variable
> in question, not its type.  Like this:
>
>    fwrite(&relocs[i].r_vaddr, 1, sizeof(relocs[i].r_vaddr), outf);

That particular one (and its similars) I can do, if the changes
are acceptable

EDIT:
It seems there are only two places where I can use the size of the
variable, one in dxe3gen.c and one in dxegen.c, both are exactly the
same. So, doing

fwrite(&(relocs[i].r_vaddr), 1, sizeof(relocs[0].r_vaddr), output_f);

... should take care of it.


> Then the code will DTRT with no changes required even if the type of
> the variable is changed.
>

EDIT:
Verdict?

--
O.S.