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:content-transfer-encoding;
	bh=vHIu0wkwe4gk842XDFjrmVI3XRN8Nn2H/HP4XDT7UlU=;
	b=dzRdctW+hTJkLz6gN4e3ccrPMUB22WcaO63/cZ1tj1BGEfbSNlo3pashfkbbXEp/9H
	gjkgZLwe4WUQM4x4H3XANsdAJvL3nVIrw2INYsi5ycSnfB0867GFJyrTjK/w5wKCDRQM
	9+qcyoMVYWp9ijmD5IdCWkyGpJd4WE0BQ1AWw=
MIME-Version:	1.0
In-Reply-To:	<83k4b0c4ya.fsf@gnu.org>
References:	<CAA2C=vCTyDxWBgYzoBB31=hoOBHJhL+famn_6XL2eYb3a_3egA AT mail DOT gmail DOT com>
	<83zkjwcknb DOT fsf AT gnu DOT org>
	<CAA2C=vBJEgnGapVsNwy7xW9HUCy0Rpxis2P5=05mxBze_qn7vQ AT mail DOT gmail DOT com>
	<83wrf0chf4 DOT fsf AT gnu DOT org>
	<CAA2C=vBtiNnx1XPVHw_6Er1uf0_biO3vpaBEa0zeYQuZKh5BxA AT mail DOT gmail DOT com>
	<83mxfwc634 DOT fsf AT gnu DOT org>
	<CAA2C=vDnictpZNcsF6UV1Did=WPvmvHM9eSQtT8R5fyTr738cA AT mail DOT gmail DOT com>
	<83k4b0c4ya DOT fsf AT gnu DOT org>
Date:	Sat, 30 Jul 2011 15:48:18 +0300
Message-ID:	<CAA2C=vCK0BR-DVYtGjezM9UgShSzkFacf-HsxWjvN5iQcBWiGQ@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
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id p6UCmNF6022595
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

On Sat, Jul 30, 2011 at 3:45 PM, Eli Zaretskii <eliz AT gnu DOT org> wrote:
>> Date: Sat, 30 Jul 2011 15:36:43 +0300
>> From: Ozkan Sezer <sezeroz AT gmail DOT com>
>>
>> >> +#ifndef _DJ_DEFINED_NATIVE_TYPES
>> >> +#define _DJ_DEFINED_NATIVE_TYPES
>> >
>> > Why are these additional macros needed?
>> >
>>
>> The types are defined in two different headers, so the guard
>> prevents multiple definition
>
> Ah, okay.  Sorry I missed that.
>
>> >>  struct external_lineno {
>> >>       union {
>> >> -             unsigned long l_symndx __attribute__((packed)); /* function name symbol index, iff l_lnno == 0 */
>> >> -             unsigned long l_paddr __attribute__((packed));          /* (physical) address of line number */
>> >> +             ULONG32 l_symndx;       /* function name symbol index, iff l_lnno == 0 */
>> >> +             ULONG32 l_paddr;                /* (physical) address of line number */
>> >>       } l_addr;
>> >>       unsigned short l_lnno;                                          /* line number */
>> >> -};
>> >> +} __attribute__((packed));
>> >
>> > Why did you remove the `__attribute__((packed))' parts (here and
>> > elsewhere)?  These structures must be binary-compatible with data
>> > produced by utilities outside of DJGPP control, so letting the
>> > compiler pad the struct members to its liking might cause subtle bugs.
>> >
>>
>> How is 'long' packed??  The intention there must be
>> to pack the structure, not the type itself.
>
> That's true, but I think some versions of the compiler needed the
> attribute on the members as well.  I'd rather leave them alone, unless
> they actually cause trouble.
>


OK, ..

>> >> -#define VALID_RELOC(r) ((r.r_type != RELOC_REL32) && (r.r_symndx != -1UL))
>> >> +#define VALID_RELOC(r) ((r.r_type != RELOC_REL32) && (r.r_symndx != 0xFFFFFFFF))
>> >
>> > I think this is cleaner:
>> >
>> >  #define VALID_RELOC(r) ((r.r_type != RELOC_REL32) && (r.r_symndx != (ULONG32)-1))
>> >
>> >> -               relocs[j].r_symndx = -1UL;
>> >> +               relocs[j].r_symndx = 0xFFFFFFFF;
>> >
>> > Same here.
>>
>> Well, is (LONG32)-1 not the same as 0xffffffff ?
>
> You meant ULONG32, I presume.

Oops, sorry, yes  ULONG32


>   This is implementation-defined, I think
> (whether sign is extended or not), and using -1 shows the intent more
> clearly, IMO.
>

OK then.  Do you need a new patch or will you edit?

--
O.S.

- Raw text -