On Sun, Jan 27, 2002 at 12:51:42AM +0200, Momchil Velikov wrote:
quoted
quoted
quoted
quoted
quoted
"Troy" == Troy Benjegerdes [off-list ref] writes:
Troy> Our div64.h macro is quite broken, and causes printk to not be able to do
Troy> a long long format.
Troy> Is there a 'fast' generic C algorithm we can replace it with, instead of
Troy> mucking with ASM?
Hmm, I sent a patchlet to lkml with Subject: [PATCH] 64-bit divide tweaks.
Doesn't it work for you ?
Didn't seee it..
Did you actually try compiling PPC this way??
vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
__umoddi3
vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
__udivdi3
--
Troy Benjegerdes | master of mispeeling | 'da hozer' | hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Did you actually try compiling PPC this way??
vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
__umoddi3
vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
__udivdi3
libgcc.a has those libraries.
Kaoru
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Did you actually try compiling PPC this way??
vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
__umoddi3
vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
__udivdi3
Kaoru> libgcc.a has those libraries.
Yeah, but we don't link with libgcc.a. (which I forgot).
I'll do something along the lines of
#ifndef __HAVE_ARCH_DO_DIV
...
#endif
... soon.
Regards,
-velco
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, Jan 28, 2002 at 10:16:28AM +0200, Momchil Velikov wrote:
quoted
quoted
quoted
quoted
quoted
"Kaoru" == Kaoru Fukui [off-list ref] writes:
Kaoru> On 27 Jan, Troy Benjegerdes wrote:
quoted
quoted
Did you actually try compiling PPC this way??
vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
__umoddi3
vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
__udivdi3
Kaoru> libgcc.a has those libraries.
Yeah, but we don't link with libgcc.a. (which I forgot).
Er, but isn't it (sort-of) considered a bug if the kernel links with
libgcc.a ? I think the consensious on l-k would be yes.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, Jan 28, 2002 at 10:16:28AM +0200, Momchil Velikov wrote:
quoted
quoted
quoted
quoted
quoted
quoted
"Kaoru" == Kaoru Fukui [off-list ref] writes:
Kaoru> On 27 Jan, Troy Benjegerdes wrote:
quoted
quoted
Did you actually try compiling PPC this way??
vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
__umoddi3
vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
__udivdi3
Kaoru> libgcc.a has those libraries.
Yeah, but we don't link with libgcc.a. (which I forgot).
Er, but isn't it (sort-of) considered a bug if the kernel links with
libgcc.a ? I think the consensious on l-k would be yes.
So you copy the code from the libgcc sources, cfr. arch/m68k/lib/.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, Jan 28, 2002 at 08:45:31PM +0100, Geert Uytterhoeven wrote:
On Mon, 28 Jan 2002, Tom Rini wrote:
quoted
On Mon, Jan 28, 2002 at 10:16:28AM +0200, Momchil Velikov wrote:
quoted
quoted
quoted
quoted
quoted
quoted
"Kaoru" == Kaoru Fukui [off-list ref] writes:
Kaoru> On 27 Jan, Troy Benjegerdes wrote:
quoted
quoted
Did you actually try compiling PPC this way??
vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
__umoddi3
vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
__udivdi3
Kaoru> libgcc.a has those libraries.
Yeah, but we don't link with libgcc.a. (which I forgot).
Er, but isn't it (sort-of) considered a bug if the kernel links with
libgcc.a ? I think the consensious on l-k would be yes.
So you copy the code from the libgcc sources, cfr. arch/m68k/lib/.
On Mon, Jan 28, 2002 at 08:45:31PM +0100, Geert Uytterhoeven wrote:
quoted
On Mon, 28 Jan 2002, Tom Rini wrote:
quoted
On Mon, Jan 28, 2002 at 10:16:28AM +0200, Momchil Velikov wrote:
quoted
quoted
quoted
quoted
quoted
quoted
"Kaoru" == Kaoru Fukui [off-list ref] writes:
Kaoru> On 27 Jan, Troy Benjegerdes wrote:
quoted
quoted
Did you actually try compiling PPC this way??
vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
__umoddi3
vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
__udivdi3
Kaoru> libgcc.a has those libraries.
Yeah, but we don't link with libgcc.a. (which I forgot).
Er, but isn't it (sort-of) considered a bug if the kernel links with
libgcc.a ? I think the consensious on l-k would be yes.
So you copy the code from the libgcc sources, cfr. arch/m68k/lib/.
Or optimize that, yes. But linking directly is a no-no. :)
Yes,it's should has the source in the kernel.
However,the other archies(arm,cris,sh) use libgcc.a with static
link.
Those makefiles have
LIBGCC := $(shell $(CC) $(CFLAGS) --print-libgcc-file-name)
If it's static link, it is same result isn't it?
Kaoru
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Tue, Jan 29, 2002 at 02:05:28PM +0900, Kaoru Fukui wrote:
On 28 Jan, Tom Rini wrote:
quoted
On Mon, Jan 28, 2002 at 08:45:31PM +0100, Geert Uytterhoeven wrote:
quoted
On Mon, 28 Jan 2002, Tom Rini wrote:
quoted
On Mon, Jan 28, 2002 at 10:16:28AM +0200, Momchil Velikov wrote:
quoted
quoted
quoted
quoted
quoted
quoted
"Kaoru" == Kaoru Fukui [off-list ref] writes:
Kaoru> On 27 Jan, Troy Benjegerdes wrote:
quoted
quoted
Did you actually try compiling PPC this way??
vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
__umoddi3
vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
__udivdi3
Kaoru> libgcc.a has those libraries.
Yeah, but we don't link with libgcc.a. (which I forgot).
Er, but isn't it (sort-of) considered a bug if the kernel links with
libgcc.a ? I think the consensious on l-k would be yes.
So you copy the code from the libgcc sources, cfr. arch/m68k/lib/.
Or optimize that, yes. But linking directly is a no-no. :)
Yes,it's should has the source in the kernel.
However,the other archies(arm,cris,sh) use libgcc.a with static
link.
Those makefiles have
LIBGCC := $(shell $(CC) $(CFLAGS) --print-libgcc-file-name)
ARM doesn't do this anymore, since it required having the correct target
libgcc around. SH is planning on moving away from this in 2.5.x from
what I understand.