This is the mail archive of the
mailing list for the glibc project.
Re: pthread_cond_* does not compile on i386
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "Gilles Carry" <Gilles dot Carry at bull dot net>
- Cc: libc-help at sourceware dot org
- Date: Mon, 5 May 2008 20:56:13 -0400
- Subject: Re: pthread_cond_* does not compile on i386
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=1K3g+dn71IaYSAL51GknYhvNreMi7aGBJv52RWox5BY=; b=LR0lWH4L333tHu2p6YHJUmbpqfjdqzQjh2zgNj047DWxu7HLGKNmWkSiC18Z5b9zVmIffzDoSvKugf9SxOsMr3Kpxqyxvintec2B9mvxDslr3LVYeUJz9XeL6i2QOZQFZhbthmqPqGo/GrPccFC4ug2AMxrsfFSATBNlkU2hN24=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=QB+08sJT0IdpYr+u/Aj4XbmB6RNNzUqPoeF7rn9sIF6vcOW2uWdxZppRXG7BQJ85eAIyWG2rlRLSfJNLXRLLfEdLy5Jcn9gy2Hxc0S3NSit5uL5P6QoD4spi3Ov1HI/TKBSPD8Ek9RwYl6vEPpMJ7FIiWkkJ/eAupgyKXEGXtDM=
- References: <48185CA9.email@example.com> <firstname.lastname@example.org> <481EAF50.email@example.com> <firstname.lastname@example.org> <481F133E.email@example.com>
On Mon, May 5, 2008 at 10:01 AM, Gilles Carry <Gilles.Carry@bull.net> wrote:
> > This is not true. Did you read this somewhere?
> I asked this on libc-alpha. The answer was:
> >Is asm code supposed to do exactly the same as C code?
> of course ... things would be broken otherwise
The C file normally includes headers that define some basic NPTL functionality.
In theory the same headers should be included in the asm
implementation, since the .S files are compiled as assembler-with-cpp.
The use of the __ASSEMBLER__ macro allows one to write macros that
work in C or asm.
>>> Should C code be the reference? Should asm be modified only when we are
>>> sure C is ok? It is a problem when people change asm code without updating
>>> the underlying C files.
> you should modify whatever your target platform uses
That's a vague response. The C code tries to be the generic reference,
but can't always in the case where the feature can't be implemented
completely in C (or safely given an optimizing compiler). The generic
C code is going to be used by targets that don't override the C file
with an asm file, so yes, it should be modified first. I would then
build and test on a target that uses the generic C file. Next you
probably want to adjust the asm that implements the C file for your
target, and test again.
Does that explanation help?
> > At one point the generic C code probably worked, but after the asm
> > files were written nobody bothered to build without them. As time
> > passed it bit rotted.
> It's a pity.
The generic C code works, but it's the i386 target that is probably
missing some of the C file implementations of certain macros.