All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Thomas <gdt@linuxppc.org>
To: Dan Malek <dmalek@jlc.net>
Cc: linuxppc-dev <linuxppc-dev@lists.linuxppc.org>
Subject: RE: Need ld.so help
Date: Sun, 27 Dec 1998 12:05:22 -0000 (GMT)	[thread overview]
Message-ID: <XFMail.981227120521.gdt@linuxppc.org> (raw)
In-Reply-To: <3685BC4F.EB0D2158@jlc.net>



On 27-Dec-98 Dan Malek wrote:
> 
> I discovered the problem I am having with the embedded 8xx
> processors and cache is that there are several assumptions
> about cache block size in various functions.  The 8xx processors
> have a 4 word (16 byte) cache line while other PPCs have
> a 8 word line.  This causes problems when trying to flush and
> invalidate caches.
> 
> One place this is done is dynamic linking functions of ld.so,
> where it is assumed a cache line is 8 words.  Unfortunately,
> I have been unable to build ld.so from the glibc SRPM.  I am
> using the 961212-1h SRPM from the linuxppc.org server, and
> the appropriate egcs and binutils.  All of the other libraries
> I build from this SRPM are fine.  From looking at the RPM of
> the same version, all of the resulting *.so files appear to be
> nearly identical, except for ld.so which is much larger than
> found in the RPM.
> 
> The details....I have tracked it down to the elf_get_dynamic_info()
> function, called from _dl_start().  The failure occurs following
> the 'while' loop.  It appears info[DT_RELA] is OK, or at least
> not NULL.  However, info[DT_RELAENT] is NULL, causing the
> program to segfault at this point.
> 
> I don't understand enough about the libraries to know where to
> look from here, so I need some help :-)
> 
> Oh yeah, the SRPM didn't build quite right.  I had to hand patch
> stdlib/exit.c.....
> 

I'm confused.  Are all of these problems attributable to the cache-line
size stuff?  Or are there other problems?

I [obviously] build the libraries directly from the SRPMS, so I'd like
to understand what your problems are.

Which software pieces are you running?
  EGCS?
  BINUTILS?
  GLIBC?
  Kernel?


------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

      reply	other threads:[~1998-12-27 12:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-12-27  4:49 Need ld.so help Dan Malek
1998-12-27 12:05 ` Gary Thomas [this message]

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=XFMail.981227120521.gdt@linuxppc.org \
    --to=gdt@linuxppc.org \
    --cc=dmalek@jlc.net \
    --cc=linuxppc-dev@lists.linuxppc.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.