Bug 31990

Summary: udivdi3 not found for linux kernel
Product: gcc Reporter: Ray Malitzke <malitzke>
Component: targetAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED DUPLICATE    
Severity: normal CC: aldot, dcb314, dnovillo, gcc-bugs, ian, kenner, manu, mark, pinskia, rakdver, ralf, rguenth, spark
Priority: P3    
Version: 4.3.0   
Target Milestone: ---   
Host: i686-unknown-linux-gnu Target: i686-unknown-linux-gnu
Build: i686-unknown-linux-gnu Known to work:
Known to fail: Last reconfirmed:
Attachments: time.i form ./kernel/time.c
timekeeping.i from ./kernel/time/timekeeping.c

Description Ray Malitzke 2007-05-18 17:07:13 UTC
I just filed (verbatim) the PR reproduced below with bugzilla.kernel.org (8501)
Hopefully the exports will be able to communicate directly.

Most recent __gcc__ compiler where this bug did *NOT* occur: gcc-4.2.0
Distribution:
Hardware Environment: x86 (will try on MAC G4 machine)
Software Environment: gcc compilers
Problem Description: "make V=1"  output

kernel/built-in.o: In function `getnstimeofday':
(.text+0x1e48d): undefined reference to `__udivdi3'
kernel/built-in.o: In function `do_gettimeofday':
(.text+0x1e5b5): undefined reference to `__udivdi3'
kernel/built-in.o: In function `update_wall_time':
Comment 1 Andrew Pinski 2007-05-18 17:29:55 UTC
First off, can you attach the preprocessed source for built-in.c ?
Second this might not be a bug in GCC but in the kernel not providing all of the required functions that are in libgcc.
Comment 2 Ray Malitzke 2007-05-18 18:57:11 UTC
Andy there you go again:

Irrelevancies and make work for others.

You folks at gcc made tons of changes in gcc-4.3 regarding machine definitions and similar. I have some evidence that some blatant mistakes were silently corrected without mentioning even ICE's in gcc bootstrap.

I refrained (wisely) from saying anything about compilations using 3Gigs of memory and then collapsing,. Now an insider has come to acknowledge that problem,PR31863.

How about your patch to overcome the PR 31541 (bit field addressing) now untouched for almost one month.

It is no wonder that a lot of packages, when I tell them about easy fixes regarding gcc-4.x.y, reply "we rather deal deal with gcc-3.x.y or even gcc-2.x( 
even with -fno-strength-reduce).

The gcc group really working hard at overcoming problems noticed by users are the gfortran people (Yes, I had my run-in with them over the goto thing, but they have not caused me to file any PR's after that)

Now to some perhaps ppoorly understood by my self technical issues:
1. binutils does a MACRO regarding udevdi3, but its is impossible to build binutils (even current CVS with gcc-4.3.0)

2. gcc-4.2.1 compiles the impacted kernel fine. To my simple, but seasoned, mind  the onus when something stops working is on the party that made changes (namley gcc going from 4.2 to 4.3); not on the one that did not change in this case
kernel-2.6.20.11.

3. I referred to to the experts in both organizations and I do not believe that you are the gcc expert in machine descriptions.
Comment 3 Andrew Pinski 2007-05-18 19:09:11 UTC
> 3. I referred to to the experts in both organizations and I do not believe that
> you are the gcc expert in machine descriptions.

Have you looked into what I have done?  Lets see my first big patch:
2002-12-02  Andrew Pinski  <pinskia@physics.uc.edu>

        * config/rs6000/rs6000.md (ffssi): Convert to expander.
        (ffsdi): Likewise.
        (cntlzw2, cntlzd2): New patterns.
And then more recently:
2007-03-31  Andrew Pinski  <andrew_pinski@playstation.sony.com>

        PR target/31364
        * config/rs6000/rs6000.md (call): Convert to LR hard reg for
        secureplt.
        (call_value): Likewise.

2006-11-29  Andrew Pinski  <andrew_pinski@playstation.sony.com>

        PR target/29945
        * config/spu/spu.md  (extend_compare<mode>): New pattern.
        (extend_compare): Change to expand and use the above pattern.

Plus this:
spu port                Andrew Pinski           andrew_pinski@playstation.sony.com

I don't see how you can say I am not an expert at this.

Also one more thing did you read http://gcc.gnu.org/bugs.html which explains exactly what we need for a bug report?

The reason why the bitfield patch has not go in yet, is because I am busy with other work and it is a minor issue on my plate right now (have you looked into what I have been doing lately?).

Also 4.3 is no where near being released in the next month or two so calm down.  We can't all fix bugs in the same time as they are reported.
Comment 4 Ray Malitzke 2007-05-18 21:11:42 UTC
Andy! 
Taking your your advice to calm down I looked for the built-in.c file you wanted preprocessed. Well, it does not exist as built-in.o is a composite object file.

The Kernel peoople being a more helpful and b) having more expertise asked for time.s and timekeeping.s out out time.c and timekeeping.c. I attached already both 
to PR8501. and you can take it from there.
Comment 5 Andrew Pinski 2007-05-18 21:59:28 UTC
(In reply to comment #4)
> Andy! 
Don't call me Andy!  It is childish.

> Taking your your advice to calm down I looked for the built-in.c file you
> wanted preprocessed. Well, it does not exist as built-in.o is a composite
> object file.

And how do I know that from your descirption of the bug?  As you just have:
kernel/built-in.o: In function `getnstimeofday':
(.text+0x1e48d): undefined reference to `__udivdi3'

Which is why I was asking for built-in.i because I thought like a normal code, it was a normal object file and not an incremental linked one.
 
> The Kernel peoople being a more helpful and b) having more expertise asked for
> time.s and timekeeping.s out out time.c and timekeeping.c. I attached already
> both 
> to PR8501. and you can take it from there.

So attach time.i and timekeeping.i here which is exactly what we need.  Note this is really only a missed optimization for GCC wise as if we call __udivdi3 now instead of doing it inlined, the code is just slower, libgcc contains __udivdi3.  So the kernel needs to add the function but we can also fix GCC so we don't produce that for a missed optimization
Comment 6 Ray Malitzke 2007-05-18 22:58:02 UTC
Created attachment 13580 [details]
time.i form ./kernel/time.c

first requested attachment
Comment 7 Ray Malitzke 2007-05-18 23:10:09 UTC
Created attachment 13581 [details]
timekeeping.i from ./kernel/time/timekeeping.c

Second requested attachemnt.

Observation:

You might just as well close on the basis of your last paragraph. 
This is really a documentation issue in getting the info to people like kernel.org and others writing programs for free-standing  or embedded systems. 
There are already udivdi3 equivalents in the kernel-tree for a number of architectures.
Maybe you can forward this to the right peopl;e within gcc or tell me who to contact.
Comment 8 Andrew Pinski 2007-05-18 23:13:38 UTC
> You might just as well close on the basis of your last paragraph. 
> This is really a documentation issue in getting the info to people like
> kernel.org and others writing programs for free-standing  or embedded systems. 
> There are already udivdi3 equivalents in the kernel-tree for a number of
> architectures.
Even if they are developing for a free standing system, libgcc is used for support  GCC and it is used by every target even the embedded ones, why the kernel guys want to duplicate this library, I have no idea, that is they only problem and not a GCC one.
Comment 9 Ray Malitzke 2007-05-18 23:45:55 UTC
Mr Pinski

I give up. I hereby formally request that you, Mr. Pinksi, refrain from having anything to do with problem reports originating from myself (Rainer Malitzke-Goes alias Ray Malitzke). I rather see them languishing unattended than having to deal with you. 
Comment 10 Andrew Pinski 2007-05-18 23:48:22 UTC
(In reply to comment #9)
> Mr Pinski
Well I am going to help now you have provided the preprocessed source for the missed optimization (since that is all what it is), read the history behind libgcc (it dates back before even the Linux kernel was even thought of).
Comment 11 Ray Malitzke 2007-05-19 02:02:41 UTC
Well, this is getting funny.

You and apparently others at gcc are looking at the computer-sofware world through a high powered telescope and in this drastically reduced field of vision you-all only see gcc. I refreshed my memory and the linux-kernel admits other compilers besides gcc, specifically for the arm hardware. 

It so happens that I started with UNIX using the Seventh Edition (late seventies) By the time of the Seventh Edition everything in Unix depended on the Ritchie assembler and the Ritchie C compiler. With the Intel i386 and the Compaq 386 I migrated to the SCO Xenix (an amalgamation of the AT&T kernel and AT&T UNIX utilities utilities plus some BSD stuff like vi and an absolutely lousy Microsoft C compiler. Even so I managed to migrate with this compiler to the Public Domain Korn Shell (pdksh).

In order to get to bash I had to hack gcc to produce xout object code (really *.s files) as the libraries were all in that xout format and to port the BSD libraries was too much work for one person. Therfore I learnt to patch gcc., and got bash as a result. I also played with the GNU utilities, but the original Unix ulities were quite adequate. This cozy little world collapsed when gcc underwent a complete rewite from gcc-2.58 to gcc-2.60 (no patches).

The salvation was in the then quite early linux kernel. But I had to hack the kernel to read the Xenix formatted hard drives with their hermaphroditic addressing. (the linux kernel to his day sports some drivers for Xenix SYSV and Coherent, but at least for Xenix these drivers work only on floppies. Thus I became probaly one the few persons, who hacked both gcc and linux. At the same time I made MS-DOS livable using the Canadian Mortice Kern (UNIX emulation) package. 

I cheerfully admit to some biases one of which is that outstanding programmers like Ritchie, Torvalds, Stallmann were also accomplished assembly language programmers and that C is really a high level and portable assembly language.
I really do not like all the stuff piled on top of the good old C. In the end, some of the stuff I hear about things like libgcc just make me smile.

I have to say that me writing this brought me some joy, probaly much more than it has for somebody reading this.
Comment 12 Richard Biener 2007-10-12 13:44:01 UTC

*** This bug has been marked as a duplicate of 32044 ***