Supervisor stack size?

[Don_Adan]

Originally Posted by Thomas Richter

Which is precisely what your proposal doesn't. Let's boil it down to one sentence: You modify a well-documented file format without being able to update the tools that depend on it. That is really it. Nothing else to say.

You are very funny. You never heard about programs or OS updates? You dont tell me single example which program can be break. I can say noone program will be break. Seems you dont heard about updated documentation. Your dirty method is not well documented too. Which tools handled your stack method? Maybe Resource? Simple you think that you know better than others, but this is not TRUE.

[phx]

Originally Posted by meynaf

I think many compilers will setup the stack as part of their startup code. Or at least they should.

No - I hope not. Why should they? Some compilers have the option to extend the stack, though.

A cookie at the right place. Perfectly detected, with stack perfecly allocated.
And then the startup code performs its regular stack swap...

Usually such a startup code should check if the stack size is already sufficient, before doing the StackSwap. At least vbcc's startup code does.

[meynaf]

Originally Posted by phx

No - I hope not. Why should they? Some compilers have the option to extend the stack, though.

There might be an option somewhere in the project settings that sets up the stack size. Hisoft C++ has this, for example. Default is 10k.

Originally Posted by phx

Usually such a startup code should check if the stack size is already sufficient, before doing the StackSwap. At least vbcc's startup code does.

Hopefully for vbcc it does.
But nobody will disassemble all startup code of every existing compiler to verify they actually do it this way...

Even if they do, we can still inadvertently end up in a situation where the stack size is smaller as given by the cookie, than what the startup code will set. Like the 10k above, if the programmer doesn't know and sets the cookie for 8k.

[phx]

Originally Posted by meynaf

Even if they do, we can still inadvertently end up in a situation where the stack size is smaller as given by the cookie, than what the startup code will set. Like the 10k above, if the programmer doesn't know and sets the cookie for 8k.

When you find out that your compiler is crap you can either remove the stack cookie again or write your own startup code.

[meynaf]

Originally Posted by phx

When you find out that your compiler is crap you can either remove the stack cookie again or write your own startup code.

In this situation it's not the compiler that's crap.

[Thomas Richter]

Originally Posted by Don_Adan

You are very funny. You never heard about programs or OS updates?

Neither SLink, BLink nor SC or GenAm are part of the Os. Nobody has its sources, probably lost somewhere at the SAS Institute, or at HiSoft, somewhere. You cannot update these tools nowadays in any practicable way.

Originally Posted by Don_Adan

I can say noone program will be break.

Then you have very limited knowledge.

Originally Posted by Don_Adan

Your dirty method is not well documented too.

Documented since day 1. Get the shell.guide from the aminet. It's there. That is the best documentation you get for the shell and I keep it updated.

Originally Posted by Don_Adan

Which tools handled your stack method?

Any compiler or assembler can be used to create the stack cookie, any linker will be able to handle the cookie correctly. No hunk-processing tool I am aware of can accidentally remove it. That is quite unlike what you propose - which is a fragile method that only happens by chance and incomplete documentation.

Originally Posted by Don_Adan

Maybe Resource? Simple you think that you know better than others, but this is not TRUE.

It will keep the cookie intact, unless you manually mess around it. That is all it needs to get it supported. Actually, that is the full trick - creating a robust method. You do not need any particular tool to get it in, and it is visible for everyone.

[Thomas Richter]

Originally Posted by meynaf

And the right section name is ?

text

Originally Posted by meynaf

Are programmers supposed to know the section name of the startup code generated by their compiler ?

You do not need to put the cookie into the startup code. Putting it into the first translation unit is usually good enough. You can put it into the startup code. But there is no need to.

[BastyCDGS]

The best way probably is having just small startup code in the program which checks if stack is large enough and if not, allocate large enough and then start with it. Works starting at OS1.x.

Also there are compilers which not only check if the stack is large enough, but expand it on the fly, as well.

I think the $STACK is a new nice addition which is esp. useful on modern AmigaOS invocations. If that's your audience, go for it! But if you also target 1.x/2.x/3.0/3.1 you should allocate the stack yourself or inform the user to use the stack cmd.

EDIT: Are the any precautions about ambigious usage of $STACK, e.g. if it's an unlucky coincidence of characters from older software?

[meynaf]

The stack cookie would have been quite acceptable if it could replace stack swap in every case. But it can't. Even if your program *requires* OS v3.9 and you're sure it will be supported. Even if you are 100% sure it is located at the right place. The reason is that it may still fail to be seen (like in the case of crunched code) or, worse, not looked for at all (if your prg isn't run from cli or wb).

Here is real life example.

When i run HOMM2 in my debugger, it does LoadSeg and then hands its stack inherited from cli to the program.
Therefore to be able to debug a program using a big stack (HOMM2 uses 32k) i'd need to type "stack" command every time. I don't want to do that !
The stack cookie can't help me : it's gonna be ignored in this case. And we're not supposed to update existing tools to use it.
So even if i did run OS V3.9 it wouldn't be able to help me.
However my asm startup code can optionnally change the stack and this is what my HOMM2 port hopefully does.
I can now debug without any special care.
Problem solved, but stack cookie useless for it.

Do you like solutions that solve a problem only in a limited number of cases ? Personnally, i don't.

[Don_Adan]

Originally Posted by Thomas Richter

Neither SLink, BLink nor SC or GenAm are part of the Os. Nobody has its sources, probably lost somewhere at the SAS Institute, or at HiSoft, somewhere. You cannot update these tools nowadays in any practicable way. Then you have very limited knowledge. Documented since day 1. Get the shell.guide from the aminet. It's there. That is the best documentation you get for the shell and I keep it updated. Any compiler or assembler can be used to create the stack cookie, any linker will be able to handle the cookie correctly. No hunk-processing tool I am aware of can accidentally remove it. That is quite unlike what you propose - which is a fragile method that only happens by chance and incomplete documentation.

It will keep the cookie intact, unless you manually mess around it. That is all it needs to get it supported. Actually, that is the full trick - creating a robust method. You do not need any particular tool to get it in, and it is visible for everyone.

Every program can be updated, via resourcing. Sources are not necessary. I dont think that for handling hunk debug someone must be updated. I dont know how unused legal hunks are handled by these linkers. Anyway you can always wrote new linker for Amiga. And authors of vbcc or/and Amiga version of GCC 6.x can updated linkers too. For adding 8 bytes at end of Amiga exe file simple file joiner is enough. Anyway if you think that your idea is really OK, add checking for LoadSeg for magic strings.

[Thomas Richter]

Originally Posted by Don_Adan

Every program can be updated, via resourcing. Sources are not necessary.

By which you create a deviate work, which you cannot distribute without permission of the copyright holder. Thus, typically impractical and illegal. Thanks, but no, thanks.

Originally Posted by Don_Adan

I dont think that for handling hunk debug someone must be updated.

But it does, and it is not a practical solution either. Once the program is loaded, the information on the stack size is lost. Yet, you may need it later. Did I say "resident"?

Originally Posted by Don_Adan

I dont know how unused legal hunks are handled by these linkers.

Precisely.

Originally Posted by Don_Adan

Anyway you can always wrote new linker for Amiga.

Thanks, I have more than enough to do. And we both know that you wouldn't write a linker either, so we better stop speculating about this stupid idea.

Originally Posted by Don_Adan

Anyway if you think that your idea is really OK, add checking for LoadSeg for magic strings.

Loadseg is the wrong place for that since the stack information is not required by loadseg in first place. It is required when executing the program, not when loading it. Which is one of the reasons for the design at hand.

[Don_Adan]

Originally Posted by Thomas Richter

By which you create a deviate work, which you cannot distribute without permission of the copyright holder. Thus, typically impractical and illegal. Thanks, but no, thanks. But it does, and it is not a practical solution either. Once the program is loaded, the information on the stack size is lost. Yet, you may need it later. Did I say "resident"? Precisely. Thanks, I have more than enough to do. And we both know that you wouldn't write a linker either, so we better stop speculating about this stupid idea. Loadseg is the wrong place for that since the stack information is not required by loadseg in first place. It is required when executing the program, not when loading it. Which is one of the reasons for the design at hand.

Then copy size of stack at any buffer if this is really needed, anyway i think that stack size is stored already, when memory for stack is allocated, because stack must be free too. Someone can wrote new linker in C or ASM, if this is problem. And this is not stupid idea. I heard something similar from you when I asked to add FORCE option for LoadModule for replacing modules with same or lower versions. And what? When AmigaOS 3.1.4 was born, something like this was added to LoadModule. Maybe is not required for LoadSeg, but this the only universal place for Amiga exe files for correct stack handling. But I forget that you dont like ASM, LoadSeg is pure 68k ASM.