public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Steve Ellcey <sellcey@mips.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: <libc-ports@sourceware.org>
Subject: Re: [patch, mips] Improved memset for MIPS
Date: Fri, 06 Sep 2013 16:50:00 -0000	[thread overview]
Message-ID: <1378486241.5770.327.camel@ubuntu-sellcey> (raw)
In-Reply-To: <Pine.LNX.4.64.1309061603380.8532@digraph.polyomino.org.uk>

On Fri, 2013-09-06 at 16:09 +0000, Joseph S. Myers wrote:

> > No.  I did most of my testing outside of the glibc testsuite because I
> > find the glibc testsuite difficult to run, see
> > https://sourceware.org/ml/libc-help/2013-08/msg00040.html for some of my
> > problems/questions.  I don't believe I have ever managed to do a clean
> 
> You'll need to debug the problems as they indicate something wrong with 
> your build environment.  It's always advised to configure glibc with 
> --prefix=/usr rather than some other prefix (but there is no requirement 
> that the dynamic linker actually be installed during testing, you can 
> ignore the -dynamic-linker= path), and your other error indicates some 
> inconsistency regarding NO_CTORS_DTORS_SECTIONS.

I have found that --prefix=/usr is more of a problem then a help when
building general cross compiler toolchains.  Using a prefix of /usr
triggers various special case code in
ports/sysdeps/unix/sysv/linux/mips/configure to put things in lib32 and
lib64 and I don't actually want any of that so I use a prefix
of /usr/fake instead of /usr.

The "undefined reference to `__libc_global_ctors'" has just shown up
again in a parallel build, but it seems to go away when I rebuild.  I am
still trying to understand what is going on with this.

> The expectation is that the glibc testsuite is the normal way to test 
> patches before submission, and string function patches like this need it 
> to be run for all six relevant ABI variants.

I think some flexibility here would be better.  There is no floating
point code in this routine so running all three ABI's in both hard and
soft float modes seems like overkill to me.  Testing in big and little
endian modes would seem more likely to turn up problems then testing in
hard and soft float.

Steve Ellcey
sellcey@imgtec.com


  reply	other threads:[~2013-09-06 16:50 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-05 17:06 Steve Ellcey 
2013-09-06  0:40 ` Mike Frysinger
2013-09-06 15:42   ` Steve Ellcey
2013-09-06  4:18 ` Carlos O'Donell
2013-09-06 16:03   ` Steve Ellcey
2013-09-06 17:12     ` Carlos O'Donell
2013-09-06 23:33       ` Steve Ellcey
2013-09-07  2:38         ` Carlos O'Donell
2013-09-10 20:31           ` Steve Ellcey
2013-09-10 21:01             ` Carlos O'Donell
2013-09-10 21:14               ` Steve Ellcey
2013-09-10 22:35                 ` Carlos O'Donell
2013-09-10 22:38                   ` Carlos O'Donell
2013-09-07  5:46         ` Andreas Schwab
2013-09-06 14:31 ` Joseph S. Myers
2013-09-06 15:58   ` Steve Ellcey
2013-09-06 16:09     ` Joseph S. Myers
2013-09-06 16:50       ` Steve Ellcey [this message]
2013-09-06 16:59         ` Joseph S. Myers
2013-09-06 17:43           ` Steve Ellcey
2013-09-06 18:57             ` Brooks Moses
2013-09-18 17:41           ` Steve Ellcey
2013-09-19 15:25             ` Carlos O'Donell
2013-09-19 17:02               ` Steve Ellcey
2013-09-20 16:43             ` Joseph S. Myers
2013-09-20 17:32               ` Steve Ellcey
2013-12-12 22:19                 ` Andrew Pinski
2013-12-13  0:01                   ` Carlos O'Donell
2013-12-13  0:14                     ` Steve Ellcey
2013-12-13  0:22                       ` Andrew Pinski
2013-12-13  4:40                       ` Carlos O'Donell
2013-09-06 16:59       ` Steve Ellcey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1378486241.5770.327.camel@ubuntu-sellcey \
    --to=sellcey@mips.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-ports@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).