Quote:
But this gives another shortcoming of the cookie in comparison to normal methods : it's not dynamic. While the program could stack swap on demand with the most appropriate size, the cookie has to contain the maximum possible size. So much for the sparing of memory it's supposed to give. Quote:
Quote:
Quote:
Quote:
Quote:
Now we have a nice bunch of data just for that. We get better every day. Quote:
Quote:
Quote:
Quote:
Remember ? You wrote "static const char". Seems it's easily missed. When will you notice the mistake ? Maybe the end user will, when he sees his program crash ? Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
|
Quote:
|
Quote:
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
If you want to speculate what should have been done 30 years ago, then I can tell you: Create a robust operating system in first place, one with memory protection and a guard page below the stack. *THAT* would have worked robustly. Unfortunately, that was not really an option for a consumer device. The hunk structure is just a minor inconvenience compared to the major issues the Os has. |
Quote:
|
Quote:
Quote:
Quote:
But what ? You did not pick this at random ? So you were the developer behind it ? That explains why you defend it so much :D Quote:
Quote:
Quote:
Quote:
Remember, if your cookie gets removed, your stack size won't change... Quote:
Quote:
Quote:
Quote:
By comparison, a program can have 1MB as first hunk, in which the stack cookie can just be missing. |
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
1. If i remember right not all legal hunks handled by LoadSeg has code (only skip bytes code is used). Choose one as Stack Size. 2. Modify debug hunk code, add extra check for stacksize ID and handle stack size. Your method is not good. |
Quote:
Quote:
Quote:
Quote:
|
Quote:
Quote:
Quote:
But the problem here isn't even the search algorithm. It is the mere fact of having to perform a search. If you don't do this, believe me, it'll be a magnitude faster. Quote:
Quote:
Quote:
Quote:
Quote:
You can prevent the removal if it's simply code that gets executed as part of the startup. And right, playing with the hunk format may be likely to break, but why not just using overlay hunks. Quote:
Only startup code is guaranteed to be in the first one, you cannot do that for any data. Quote:
Quote:
Quote:
Resident tags are mandatory for libraries and devices so the search will hopefully end with a success - and needs not be fast otherwise. On the other hand, not even 1% of executables that'll run actually contain the stack cookie and it'll be searched in vain by scanning all of their first hunk entirely. Definitely not the same situation. Quote:
|
Quote:
I know, that you think that your version is good, but this is useless, only wasting some bytes or kilobytes in Amiga ROM space. If my ideas are really bad, then we can try to find other clear solution for stacksize support. For me your way is dirty hack only, not clean way. |
Quote:
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
Quote:
What you did here is a typical behavior of people out of argument. I didn't know you were the type, though. This is deceiving. Aren't you better than that ? Anyhow, my "very limited experience" tells me that none of your tricks will guarantee you get the cookie in the right hunk. It works for you purely by luck. Ok, it will not be stripped (at the price of something quite ugly). So it will be in your executable and still possibly in the wrong section. The fact it never happens in your setup isn't a proof it can't happen at all. IOW, "works for me" isn't a correct reply. Quote:
The point here was that you have some table (256 bytes ?) that is there permanently eating memory, just to spare a few temporary kb in some rare cases. Clear now ? Quote:
But indeed it's probably not noticeable. Neither is the second stack when doing a swap. Quote:
Quote:
Quote:
Gains i get by rewriting parts of compiled code into asm easily spare a lot more bytes than that little "waste" uses. Quote:
The fact the cookie is still there for resident programs may seem a good argument for it... ... Except for the fact resident made programs are quite rare in current setups, and they are for small, often used commands that of course don't need big stacks. Quote:
And i don't put hacks in programs when i can do otherwise. Quote:
Quote:
Quote:
Quote:
And yes, ROM-based segments can have a stack cookie -- but neither libraries, devices, resources, nor small resident commands need to use something like that. Quote:
And again you can not tell the compiler in which hunk to put things. Quote:
But i don't really care if it sticks or not, even if i would certainly delete it if i had to rewrite the OS. At least it's relative harmless. |
Quote:
Quote:
I think the STACK cookie is a good idea. There is nothing bad about it (I don't care about a few cycles scanning for it at program start) and it is implemented in a flexible, backwards-compatible way. Other operating systems, like Atari MiNT, have a similar cookie. My problem is that it is much too late. In my software I would never expect that most users are running 3.9 or 3.1.4, or even requiring it. So I will still use StackSwap() to be safe. Now I need to know: which additional advantage would I get by including the STACK cookie? When it means that the STACK cookie launches my program with a large enough stack, so that StackSwap() is no longer needed under 3.9/3.1.4, then I should probably add it. I will check the current stack size anyway, so I can avoid StackSwap() when the stack was already large enough. |
Quote:
Quote:
Quote:
But as it's taking its toll regardless if wanted or not, indeed why not using it. |
Quote:
|
Quote:
Are programmers supposed to know the section name of the startup code generated by their compiler ? |
Another problem i'm just thinking about.
Even if the stack cookie is there and honored, things can still go haywire. I think many compilers will setup the stack as part of their startup code. Or at least they should. Now the programmer, not knowing about this fact, will put the cookie in his code. A cookie at the right place. Perfectly detected, with stack perfecly allocated. And then the startup code performs its regular stack swap... |
All times are GMT +2. The time now is 08:18. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.