From: David Howells <dhowells@redhat.com>
To: Jan Dittmer <jdi@l4x.org>
Cc: dhowells@redhat.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Working frv toolchain?
Date: Tue, 06 Nov 2007 21:47:15 +0000 [thread overview]
Message-ID: <3834.1194385635@redhat.com> (raw)
In-Reply-To: <4730D713.7060406@l4x.org>
Jan Dittmer <jdi@l4x.org> wrote:
> > Can you try the attached patch?
>
> Thanks, that fixes the error in question.
Excellent. I'll post it on upstream.
> Are there any chances to get a patch for frv support against
> some upstream gcc 4.x version?
Do you mean a patch to gcc? Apparently gcc 4.3 should be fine, but I haven't
been able to build a toolchain that includes it. I'm currently stuck on
trying to get through the glibc build phase.
> Now I have only a couple of scary looking warnings (see below, sorry for the
> word-wrap).
> ...
> frv-linux-gnu-ld: Warning: size of symbol `sys_set_robust_list' changed from 8
> in kernel/sys_ni.o to 32 in kernel/futex.o
Yeah. Dunno what to do about that. I suspect I need to do something about
cond_syscall(), but I'm not sure what.
> WARNING: vmlinux.o(.text+0x40): Section mismatch: reference to
> .init.text:free_initmem (between 'init_post' and 'try_name')
It's entirely possible that free_initmem() should not itself be marked __init.
> WARNING: vmlinux.o(.text+0x54fc): Section mismatch: reference to
> .init.text:start_kernel (between 'debug_stub' and 'debug_stub_exit')
> WARNING: vmlinux.o(.text+0x5500): Section mismatch: reference to
> .init.text:start_kernel (between 'debug_stub' and 'debug_stub_exit')
debug_stub() needs to arrange for start_kernel() to be invoked on its first
entry, but can't itself be __init because it gets invoked on every debugging
event (single step, h/w breakpoints, break instruction, etc). However, its
first call is right at the end of head.S, so it isn't actually a problem.
Note that it isn't possible to jump directly into the debugger. You have to
take an debug-level exception to enter CPU debug mode - which is a level higher
than kernel mode.
> WARNING: vmlinux.o(.text+0xf7b48): Section mismatch: reference to
> .init.text:pcibios_fixup_bus (between 'pci_scan_child_bus' and
> 'pci_scan_bridge')
Hmmm... pci_scan_child_bus() is not __*init, but it calls pcibios_fixup_bus()
which is. That smells a trifle fishy.
David
prev parent reply other threads:[~2007-11-06 21:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-29 10:26 Working frv toolchain? Jan Dittmer
2007-10-29 13:06 ` David Howells
2007-10-29 19:24 ` Jan Dittmer
2007-10-30 14:17 ` David Howells
2007-10-30 14:18 ` David Howells
2007-10-30 16:06 ` Jan Dittmer
2007-11-02 21:19 ` Jan Dittmer
2007-11-03 10:58 ` David Howells
2007-11-04 15:54 ` Jan Dittmer
2007-11-05 16:04 ` David Howells
2007-11-06 21:05 ` Jan Dittmer
2007-11-06 21:47 ` David Howells [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=3834.1194385635@redhat.com \
--to=dhowells@redhat.com \
--cc=jdi@l4x.org \
--cc=linux-kernel@vger.kernel.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