public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
* some status
@ 2000-03-28 10:08 Ulrich Drepper
  2000-03-29  5:12 ` Andreas Jaeger
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Ulrich Drepper @ 2000-03-28 10:08 UTC (permalink / raw)
  To: GNU libc hacker

On Sunday (thanks to rth's help) I was able to compile glibc for the
first time since January using the current egcs.  A big step.

What I did first was looking for problems in localedef.  I knew there
were memory corruptions.  This is why these mcheck() changes went in
in the last days.  They are pretty effective ato find these problems.
The problems were in obstack_printf which should now work.

This morning I checked in a change to handle unaligned buffers in
iconv().  Bruno reported this and he's right.  I still didn't want to
loose the fast method if the user is sane enough and passes in
appropriately aligned buffer.  Therefore we have now this even more
complicated recursive inclusion of loop.c.  I have not tested it on
machines which require this so please, give it a try.  I don't have
access to a machine which requires this.

I'm slowly nearing the bottom of the pile of emails I haven't handled
so far.  I'll let you know when I think I'm done so that you can
resend messages containing patches/bugs I missed.

Yesterday I started looking at the IA-64 changes and I'm making very
slow progress.  The biggest problem are the patches which change
generic code and this in a way which penalizes other architectures.
This is of course not acceptable.  So I have to rewrite the code but
this takes time.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: some status
  2000-03-28 10:08 some status Ulrich Drepper
@ 2000-03-29  5:12 ` Andreas Jaeger
  2000-03-29  7:58   ` Ulrich Drepper
  2000-03-30  4:16 ` Jakub Jelinek
  2000-03-31  4:54 ` Andreas Jaeger
  2 siblings, 1 reply; 5+ messages in thread
From: Andreas Jaeger @ 2000-03-29  5:12 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: GNU libc hacker

>>>>> Ulrich Drepper writes:

 > On Sunday (thanks to rth's help) I was able to compile glibc for the
 > first time since January using the current egcs.  A big step.

and another big step: The current glibc passes `make check' again for
me!

[...]
 > Yesterday I started looking at the IA-64 changes and I'm making very
 > slow progress.  The biggest problem are the patches which change
 > generic code and this in a way which penalizes other architectures.
 > This is of course not acceptable.  So I have to rewrite the code but
 > this takes time.
Are these patches available somewhere?  Or can you send the current
version to the list?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: some status
  2000-03-29  5:12 ` Andreas Jaeger
@ 2000-03-29  7:58   ` Ulrich Drepper
  0 siblings, 0 replies; 5+ messages in thread
From: Ulrich Drepper @ 2000-03-29  7:58 UTC (permalink / raw)
  To: GNU libc hacker

Andreas Jaeger <aj@suse.de> writes:

> Are these patches available somewhere?  Or can you send the current
> version to the list?

I'm probably not working from the latest version.  I have a snapshot
of the Trillian libc version.  I can get it yourself.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: some status
  2000-03-28 10:08 some status Ulrich Drepper
  2000-03-29  5:12 ` Andreas Jaeger
@ 2000-03-30  4:16 ` Jakub Jelinek
  2000-03-31  4:54 ` Andreas Jaeger
  2 siblings, 0 replies; 5+ messages in thread
From: Jakub Jelinek @ 2000-03-30  4:16 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: GNU libc hacker

On Tue, Mar 28, 2000 at 10:06:10AM -0800, Ulrich Drepper wrote:
> On Sunday (thanks to rth's help) I was able to compile glibc for the
> first time since January using the current egcs.  A big step.
> 
> What I did first was looking for problems in localedef.  I knew there
> were memory corruptions.  This is why these mcheck() changes went in
> in the last days.  They are pretty effective ato find these problems.
> The problems were in obstack_printf which should now work.
> 
> This morning I checked in a change to handle unaligned buffers in
> iconv().  Bruno reported this and he's right.  I still didn't want to
> loose the fast method if the user is sane enough and passes in
> appropriately aligned buffer.  Therefore we have now this even more
> complicated recursive inclusion of loop.c.  I have not tested it on
> machines which require this so please, give it a try.  I don't have
> access to a machine which requires this.

It does not even compile.
With the patch below it already compiles, but does not link nor is expected
to work (but as I'm now in midst of testing gcc I did not hack on this any
further). Basically, the remaining issues in my eyes are:
undefined references to internal_ucs4_loop_unaligned and
internal_ucs4le_loop_unaligned - I guess best would be if
internal_ucs4_loop was moved into yet another C file and would be included
twice (for ucs4 and ucs4le) plus it would include itself once like loop.c
does now.
the other issue is that get16/get32/put16/put32 macros are not used
anywhere, so I guess it requires some time to go and check all memory
dereferences and see if it can be unaligned or not.

--- iconv/skeleton.c.jj	Wed Mar 29 16:07:06 2000
+++ iconv/skeleton.c	Thu Mar 30 13:36:14 2000
@@ -305,22 +305,21 @@ FUNCTION_NAME (struct __gconv_step *step
 	 beginning, either don't have the minimal number of bytes as a divisor
 	 of the maximum length or have a minimum length of 1.  This is true
 	 for all known and supported encodings.  */
-      int unaligned;
-
-      unaligned = ((FROM_DIRECTION
-		    && ((MIN_NEEDED_FROM > 1
-			 && MAX_NEEDED_FROM % MIN_NEEDED_FROM == 0
-			 && (uintptr_t) inptr % MIN_NEEDED_FROM != 0)
-			|| (MIN_NEEDED_TO > 1
-			    && MAX_NEEDED_TO % MIN_NEEDED_TO == 0
-			    && (uintptr_t) outbuf % MIN_NEEDED_TO != 0)))
-		   || (!FROM_DIRECTION
-		       && ((MIN_NEEDED_FROM > 1
-			    && MAX_NEEDED_FROM % MIN_NEEDED_FROM == 0
-			    && (uintptr_t) outbuf % MIN_NEEDED_FROM != 0)
-			   || (MIN_NEEDED_TO > 1
-			       && MAX_NEEDED_TO % MIN_NEEDED_TO == 0
-			       && (uintptr_t) inptr % MIN_NEEDED_TO != 0))));
+      int unaligned =
+	((FROM_DIRECTION
+	  && ((MIN_NEEDED_FROM > 1
+	       && MAX_NEEDED_FROM % MIN_NEEDED_FROM == 0
+	       && (uintptr_t) inptr % MIN_NEEDED_FROM != 0)
+	      || (MIN_NEEDED_TO > 1
+		  && MAX_NEEDED_TO % MIN_NEEDED_TO == 0
+		  && (uintptr_t) outbuf % MIN_NEEDED_TO != 0)))
+	 || (!FROM_DIRECTION
+	     && ((MIN_NEEDED_FROM > 1
+		  && MAX_NEEDED_FROM % MIN_NEEDED_FROM == 0
+		  && (uintptr_t) outbuf % MIN_NEEDED_FROM != 0)
+		 || (MIN_NEEDED_TO > 1
+		     && MAX_NEEDED_TO % MIN_NEEDED_TO == 0
+		     && (uintptr_t) inptr % MIN_NEEDED_TO != 0))));
 # define GEN_unaligned(name) GEN_unaligned2 (name)
 # define GEN_unaligned2(name) name##_unaligned
 #endif
@@ -486,3 +485,8 @@ FUNCTION_NAME (struct __gconv_step *step
 #undef FUNCTION_NAME
 #undef PREPARE_LOOP
 #undef END_LOOP
+
+#undef get16
+#undef get32
+#undef put16
+#undef put32
--- iconv/loop.c.jj	Wed Mar 29 16:07:06 2000
+++ iconv/loop.c	Thu Mar 30 13:59:14 2000
@@ -71,23 +71,28 @@
 
 # define FCTNAME2(name) name
 #else
+# ifdef DEFINE_UNALIGNED
+#  undef get16
+#  undef get32
+#  undef put16
+#  undef put32
 /* Distinguish between big endian and little endian.  */
-# if __BYTE_ORDER == __LITTLE_ENDIAN
-#  define get16(addr) \
+#  if __BYTE_ORDER == __LITTLE_ENDIAN
+#   define get16(addr) \
      (((__const unsigned char *) (addr))[1] << 8			      \
       | ((__const unsigned char *) (addr))[0])
-#  define get32(addr) \
+#   define get32(addr) \
      (((((__const unsigned char *) (addr))[3] << 8			      \
 	| ((__const unsigned char *) (addr))[2]) << 8			      \
        | ((__const unsigned char *) (addr))[1]) << 8			      \
       | ((__const unsigned char *) (addr))[0])
 
-# define put16(addr, val) \
+#   define put16(addr, val) \
      ({ uint16_t __val = (val);						      \
 	((__const unsigned char *) (addr))[0] = __val;			      \
 	((__const unsigned char *) (addr))[1] = __val >> 8;		      \
 	(void) 0; })
-# define put32(addr, val) \
+#   define put32(addr, val) \
      ({ uint16_t __val = (val);						      \
 	((__const unsigned char *) (addr))[0] = __val;			      \
 	__val >>= 8;							      \
@@ -97,22 +102,22 @@
 	__val >>= 8;							      \
 	((__const unsigned char *) (addr))[3] = __val;			      \
 	(void) 0; })
-# else
-#  define get16(addr) \
+#  else
+#   define get16(addr) \
      (((__const unsigned char *) (addr))[0] << 8			      \
       | ((__const unsigned char *) (addr))[1])
-#  define get32(addr) \
+#   define get32(addr) \
      (((((__const unsigned char *) (addr))[0] << 8			      \
 	| ((__const unsigned char *) (addr))[1]) << 8			      \
        | ((__const unsigned char *) (addr))[2]) << 8			      \
       | ((__const unsigned char *) (addr))[3])
 
-# define put16(addr, val) \
+#   define put16(addr, val) \
      ({ uint16_t __val = (val);						      \
 	((__const unsigned char *) (addr))[1] = __val;			      \
 	((__const unsigned char *) (addr))[2] = __val >> 8;		      \
 	(void) 0; })
-# define put32(addr, val) \
+#   define put32(addr, val) \
      ({ uint16_t __val = (val);						      \
 	((__const unsigned char *) (addr))[3] = __val;			      \
 	__val >>= 8;							      \
@@ -122,6 +127,12 @@
 	__val >>= 8;							      \
 	((__const unsigned char *) (addr))[0] = __val;			      \
 	(void) 0; })
+#  endif
+# else
+#  define get16(addr) *((uint16_t *) (addr))
+#  define get32(addr) *((uint32_t *) (addr))
+#  define put16(addr, val) *((uint16_t *) (addr)) = (val)
+#  define put32(addr, val) *((uint32_t *) (addr)) = (val)
 # endif
 
 # define FCTNAME2(name) name##_unaligned


Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.99-pre2 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: some status
  2000-03-28 10:08 some status Ulrich Drepper
  2000-03-29  5:12 ` Andreas Jaeger
  2000-03-30  4:16 ` Jakub Jelinek
@ 2000-03-31  4:54 ` Andreas Jaeger
  2 siblings, 0 replies; 5+ messages in thread
From: Andreas Jaeger @ 2000-03-31  4:54 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: GNU libc hacker

>>>>> Ulrich Drepper writes:

 > This morning I checked in a change to handle unaligned buffers in
 > iconv().  Bruno reported this and he's right.  I still didn't want to
 > loose the fast method if the user is sane enough and passes in
 > appropriately aligned buffer.  Therefore we have now this even more
 > complicated recursive inclusion of loop.c.  I have not tested it on
 > machines which require this so please, give it a try.  I don't have
 > access to a machine which requires this.
Just #undef _STRING_ARCH_unaligned in skeleton.c and loop.c after the
inclusion of <string.h> - and you'll notice a lot of problems.

Btw. I'm leaving tomorrow for California and will not have time to
look at the glibc bug reports.  Could others handle them, please?  I'm
back after easter.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2000-03-31  4:54 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-28 10:08 some status Ulrich Drepper
2000-03-29  5:12 ` Andreas Jaeger
2000-03-29  7:58   ` Ulrich Drepper
2000-03-30  4:16 ` Jakub Jelinek
2000-03-31  4:54 ` Andreas Jaeger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).