I hope it compiles.
|
| Author | Content |
|---|---|
| Bob_Robertson Mar 15, 2011 9:20 PM EDT |
I've been getting an error when trying to compile the last couple of 2.6.38-rc, some assembler code doesn't evaluate to a constant. Let's hope that's fixed in the release, or I'll have to wait until Debian packages it, and who knows how that THAT will take! |
| Bob_Robertson Mar 16, 2011 3:22 PM EDT |
Oh well.. arch/x86/kernel/entry_32.S: Assembler messages: arch/x86/kernel/entry_32.S:1422: Error: .size expression does not evaluate to a constant make[3]: *** [arch/x86/kernel/entry_32.o] Error 1 |
| Steven_Rosenber Mar 16, 2011 3:31 PM EDT |
Nothing yet from Liquorix: http://liquorix.net/sources/ |
| Bob_Robertson Mar 16, 2011 3:52 PM EDT |
I found the error has been posted to the Linux Kernel Mailing List, so people know about it. |
| Steven_Rosenber Mar 17, 2011 12:24 AM EDT |
I'm downloading 2.6.37-4. I took a few weeks off of kernel updates. |
| Bob_Robertson Mar 17, 2011 9:33 AM EDT |
Well I'm running 2.6.38-rc6, which compiled just fine. Then with -rc7 I got the "evaluate" error above, so I let it go until -rc8 where it happened again. Since it's obvious that such an error would have been fixed from one rc to the next, I went looking. One of the LKML posters had commented about it, so I sent him a note asking if it had been fixed, since being just a lowly user I don't feel comfortable posting such a thing to the LKML, and his reply was that I needed to do some GIT thing. ...but I don't use GIT, so I let it go, figuring that it would be certain to be resolved before being released as a mainline kernel. Nope. Still happens. So it's either JUST ME, or something that real programmers think is so trivial that no one cares about it but me. |
| herzeleid Mar 17, 2011 1:19 PM EDT |
Bob, you ought to go ahead and post that error to lkml. While the lkml members have little patience with trolls and do not suffer fools gladly, they will certainly be receptive to your message as long as you are brief, clear and to the point. |
| Bob_Robertson Mar 17, 2011 1:36 PM EDT |
Herz, Except that it has been posted, and replied to. That's where I found it mentioned. https://patchwork.kernel.org/patch/606241/ which is pretty much just three emails on the LKML. I guess I could send a message that this problem occurred with the two -rc versions and then the main release, but I have to seriously consider if it were happening to anyone else, why would it have been released? I should think "does not compile" would be one of those regressions people would take seriously. So if I do, it will look exactly like a troll or fool. |
| herzeleid Mar 17, 2011 1:53 PM EDT |
@Bob - As long as you logically present the facts of what you are seeing, you won't look like a troll. It may be that your hardware is some sort of corner case, but I think they'll be interested to know, just the same. |
| Bob_Robertson Mar 17, 2011 7:08 PM EDT |
Well, I did it and I got a reply. Although you could just do a search on the LKML, the gist of it is: ======= The problem is that we have macros that create functions for us in assembly: ENTRY(foo) [ body of foo ] END(foo) But there also are some areas where we had a typo: ENTRY(foo) [ body of foo ] END(xfoo) binutils version 2.20 and before ignored this little bug. Version 2.21 now fails with the error you get. Sure we can go about fixing this bug, but because of this stupid decision by the developers of binutils, older kernels will no longer build. The correct thing for them to have done, was just to make it into a warning and not fail the entire build. ========= And sure enough, when I went into arch/x86/kernel/entry_32.S, I found this: ======== ENTRY(resume_userspace) ... END(ret_from_exception) #ifdef CONFIG_PREEMPT ENTRY(resume_kernel) ... END(resume_kernel) ======== Note how the first ENTRY/END pair doesn't match, but the second one does. I replied to the person who sent me the comment above asking if it is as simple as changing the END to match the ENTRY, and if it is then I'll try it and see. Maybe, just maybe, I've done some little bit of good. |
| herzeleid Mar 17, 2011 7:20 PM EDT |
Verrry interesting. Thanks for supplying those details. |
| Bob_Robertson Mar 18, 2011 8:18 AM EDT |
My LKML contact reported back that, yes, simply changing the names to match should do the trick. Holy Bug, Batman! If I can figure out how to submit a patch, I can be a KERNEL DEVELOPER! Wahoo! |
| hkwint Mar 18, 2011 8:32 AM EDT |
Bob the Assembly Macro Stachelmeister... Sounds nice to me! |
| Bob_Robertson Mar 18, 2011 8:41 AM EDT |
Blast. Spoke too soon. This is where it shows that "I'm not a programmer". So the labels in "ENTRY(this text doesn't matter)" don't matter, but they should match. I assume (ah HA! -assume-) that each ENTRY() has to have a matching END(). I assume (again?) that this must be the pattern: ENTRY(a) ENTRY(b) END(b) END(a) but even in this one file, arch/x86/kernel/entry_32.S, the nesting is such that the labels say: ENTRY(a) ENTRY(b) END(a) END(b) or even (c) The logician in me says, "make the labels match, because the old binutils ignored what was in the text and matched the nested ENTRY() and END() by position" But I'm old enough to know that logic is not paramount in human action, so even something as clear as that isn't always going to be true. Argh. Time to send some email to actual programmer friends. Of course, this will likely be fixed long before I get it straight. Argh again. |
| fewt Mar 18, 2011 4:02 PM EDT |
We have 2.6.38 in Fuduntu Testing right now, it's proving to be pretty solid. :D |
| gus3 Mar 18, 2011 5:12 PM EDT |
And I have 2.6.38 running on both my Slackware machines. So nyeah! |
| jimbauwens Mar 19, 2011 7:05 PM EDT |
I have it running on my netbook, and no problems so far.
I also notice improvements in speed, and I'm happy with it. Drivers for display link devices++; Driver for touchpad++; Driver for wifi++; |
| Bob_Robertson Mar 20, 2011 9:31 AM EDT |
Oh, I agree, 2.6.38-rc6 is working great. |
| Bob_Robertson Mar 20, 2011 11:34 AM EDT |
I submitted the following patch to the LKML, since there was no maintainer listed in the file other than Linus himself: --- entry_32.S.original 2011-03-18 08:21:51.000000000 -0400 +++ entry_32.S 2011-03-20 10:37:00.000000000 -0400 @@ -343,7 +343,7 @@ # int/exception return? jne work_pending jmp restore_all -END(ret_from_exception) +END(resume_userspace) #ifdef CONFIG_PREEMPT ENTRY(resume_kernel) @@ -1413,7 +1413,7 @@ CFI_ADJUST_CFA_OFFSET 4 jmp error_code CFI_ENDPROC -END(apf_page_fault) +END(async_page_fault) #endif /* |
| Steven_Rosenber Mar 21, 2011 1:49 PM EDT |
Whoa! Now you're doing kernel patches :{) |
| Bob_Robertson Mar 21, 2011 5:38 PM EDT |
Yeah, I've been strutting around like the cat that ate the canary. I mean, seriously, of all the things I never EVER thought I would be doing, considering how I do not consider myself to be a programmer by any stretch of the word. But for decades I've done complex configuration and troubleshooting on network hardware. Given something that already (mostly) runs, I can debug it. My biggest worry with that was whether or not the labels I changed had to match what was used to call them. So I took a leap of logic and changed only the END(foo) statements to match the ENTRY(foo). Only two were "wrong", which helped greatly since if there had not been examples within the same file of the same calls that _WORKED_, I would have been even more hesitant. ...and it worked. I compiled it and have been running it ever since. |
| Steven_Rosenber Mar 21, 2011 5:45 PM EDT |
This is how it starts ... |
| Bob_Robertson Mar 21, 2011 7:50 PM EDT |
I wonder if I can make "Gonna get my email address in the change file, in the change file of the Linux kernel!" work to the tune of "On The Cover Of The Rolling Stone". Oh well. I have shot a diff into the air. It may be included I know not where. |
| gus3 Mar 21, 2011 9:09 PM EDT |
I shot a diff into the Ether, and it stuck... |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!