linux-kernel - Re: Working frv toolchain?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3834.1194385635@redhat.com>
Date:	Tue, 06 Nov 2007 21:47:15 +0000
From:	David Howells <dhowells@...hat.com>
To:	Jan Dittmer <jdi@....org>
Cc:	dhowells@...hat.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Working frv toolchain?

Jan Dittmer <jdi@....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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/