ERROR Compiling Kernel:

Yuri Ferreira · n00b Joined: 23 Oct 2017 Posts: 17 Location: 2121

ERROR Compiling Kernel:

make && make modules_install

I GET:

CHK include/config/kernel.release
Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by_compiler
make: ***** [Makefile:1085: prepare-compiler-check] Error 1
_________________
2121212

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

Post your emerge --info.

Jaglover · Posted: Mon Oct 23, 2017 8:18 pm Post subject:

And output of pwd -P while in kernel sources directory, just in case.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

Yuri Ferreira · n00b Joined: 23 Oct 2017 Posts: 17 Location: 2121

Sorry, i'm Brazilian.
I have dificulty in gentoo linux because i'm a Beginner.
PWD -P

/usr/linux-4.12.12-gentoo
_________________
2121212

NeddySeagoon · Posted: Mon Oct 23, 2017 9:00 pm Post subject:

Yuri Ferreira,

krinn · Watchman Joined: 02 May 2003 Posts: 7470

if i remember well last time i saw that, user was using a gcc <5, upgrade gcc first

NeddySeagoon · Posted: Mon Oct 23, 2017 10:29 pm Post subject:

krinn,

Correct but baby steps.
The gcc upgadae means rebuilding all the C++ code for the ABI change. I suspect that the out of date gcc is hinting an an out of date install, thus its only the tip of the iceberg.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

That error message, assuming it's accurate, suggests gcc <4.2. That isn't even ancient history at this point, it's early cretaceous.

krinn · Watchman Joined: 02 May 2003 Posts: 7470

steveL · Posted: Tue Oct 24, 2017 11:16 am Post subject:

Yuri Ferreira · n00b Joined: 23 Oct 2017 Posts: 17 Location: 2121

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

steveL · Posted: Thu Oct 26, 2017 11:38 am Post subject:

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

steveL · Posted: Fri Dec 15, 2017 6:44 pm Post subject:

steveL · Posted: Fri Dec 15, 2017 6:45 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

In x86 assembly, there are instructions for calling to a function and instructions for returning from a function (yes, plural in both cases). Call implicitly pushes $ip onto the stack, then transfers control to the target. Return implicitly pops from the stack into $ip. The stack for return addresses is designated by $esp/$rsp (x86/x86_64), and you cannot change that without changing the CPU ISA. You could, in theory, design a software ABI where $esp/$rsp is never used for any locals, effectively reserving the stack pointer to be only for return addresses. You would then need to spend an additional register tracking your stack-of-locals. It's not technically impossible to fix this in software, but it's very ugly. It gets worse when you consider some special purpose low level code that needs access to temporary storage, but runs in a context where the stack may be the only storage available.

bunder · Bodhisattva Joined: 10 Apr 2004 Posts: 5934

I didn't notice this problem on most of my machines, save one... the one running an old hardened-sources. I wound up patching the makefile, because I already have stack protector turned off. I don't know if this is the correct way, but it does seem to work.

steveL · Posted: Sat Jan 06, 2018 8:41 am Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

Historically, x86 has been considered register-starved relative to most other ISAs. x86_64 made this suck less. As a consequence of this starvation, any scheme that reserves extra register(s) needs to have a very good justification or people will dismiss it due to the performance problems caused by the increased spills. I approach new schemes with that same skepticism.

As a point of clarification, which categories are you advocating go on which stacks? We need to track return addresses, function parameters, and function locals. We could group all function locals together or subdivide them into scalar locals (which only turn into overruns when people do something very stupid and treat a scalar as an array) and array locals (which overrun merely by forgetting to check the array length). In the latter case, even some relatively complex functions could be done entirely on a single stack. I replied on the basis that a data stack stores all data, and a codeflow stack stores only return addresses, and nothing else.

Assuming you want the control-stack to be exclusively return addresses, with all data moved to another stack, you get into a practical irritation. The CPU has lots of nice instructions for managing a combined data/codeflow stack via esp/rsp. If you want to separate them, and you don't redesign the ISA, there are various instructions you no longer get to use because they're hardwired to use $sp as their memory reference (push, call, ret, pop being the most common always-$sp instructions). So either you designate $sp as your data stack, then forgo easy use of call and return, or you designate $sp as your codeflow stack, then forgo easy use of push/pop. Both are possible, but may generate worse code compared to using the instructions designed for this access, hence "very ugly."

I say "in theory" because I am not aware of any production or seriously-proposed-for-production x86_32 or x86_64 ABI which works as you describe. I am aware that this is not new in the abstract, but as far as I know, it has never been done in production on x86 chips.

Regarding IRQs, my point was that when an IRQ handler triggers, the CPU is responsible for preparing the registers before it begins executing the IRQ handler. Some of that preparation is based on loading values that the OS prepared when the IRQ handler was installed, but my concern, which I did not research at the time, is whether the OS can prearrange enough state that an IRQ handler, using only whatever the CPU did autonomously and any prearrangements from earlier OS code, can get both a usable data stack and usable code stack, and do so without needing to write to whichever one it starts without. Based on your comment about not wanting a data stack in IRQ context, you may have intended that a "data stack" is only for that data which is more readily misused. I interpreted it much more strictly, as being that the data stack is used for everything except return addresses. If so, there's very little that can be done to obtain a data stack because there is very little scratch space, so the handler would need to receive one preinitialized by the OS, and discoverable with very little code in the handler. If we say that the control-flow stack can also be used to store spilled registers and function arguments, an IRQ handler can do quite a bit of useful work using only the control-flow stack, and might well be able to obtain a data stack if one were needed.

steveL · Posted: Sun Jan 14, 2018 6:23 pm Post subject:

steveL · Posted: Sat May 05, 2018 10:21 am Post subject:

@Hu: My mistake; as notadev pointed out, the search term you want is "Forth data-stack Z80" (wrt prior art.)
Also, it's not just random user input; it is random external observable data.

Pretending it's anything other than garbage in terms of machine-control information, and relying on human programmers who cannot even see the asm, is both wildly stupid and wilfully blind to Law 0, and Law 1 of Computing: GIGO.