04 July 2024, 10:37 | #21 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,553
|
I didn't read everything, so just as a side note: I think that Small Data is generally a bad choice for a shared library. You have to save and restore the Small Data base pointer (to the __MERGED section in A4) in every single library function and callback (using
__saveds). Additionally you steal register A4 from the code generator. This is quite some waste as a good library shouldn't have any static data sections at all. Best practice is to store everything in the library base structure, which also provides you fast base-relative addressing (with A4 still available). I wouldn't be surprised if this also solves your static variable problems. Edit: And constant data, like your TagItem structure, should get a constattribute, so the compiler can place it into the code section for PC-relative addressing. Last edited by phx; 04 July 2024 at 10:44. Reason: cost |
04 July 2024, 11:33 | #22 | |||
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 174
|
Quote:
To be on the safe side, I tested again now. It does not seem to make any difference. The library was at 084c08a4. And the variable in question at 0811DA9A again. I also checked that all library functions that call new_app_entry() has __saveds, and they do. They are all in the same .c file, and are the previously mentioned L_WB_AddAppMenuItem(), L_WB_AddAppIcon() and L_WB_AddAppWindow(). Attaching disassembly of the file in question with __saveds added to new_app_entry(). Quote:
But as I understand it there is no way to avoid using __saveds when making libraries the "SAS/C way", because it uses the the presence of the combination of __asm and __saveds to identify the functions that should be exported by the library. Quote:
*Edit: For this variable only, not everything. And I must admit that I did not trace back the original allocation of the struct I put it in. It might be a allocated with AllocVec(). Yea, I do believe my first task after this is to go trough the library code and add const to maybe all the static variables. While I found only on function-local example, there where lots of similar examples outside function scope. Last edited by hceline; 04 July 2024 at 15:06. Reason: Correction and clarification of previous edit |
|||
04 July 2024, 19:51 | #23 | |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 174
|
To know for sure the disassembly matched the code I was running I put a MuForce hit after the first KPrinF() in both L_AddScrollBars() and new_app_entry() like this:
Code:
{ volatile char *a = 0; *a = 0; } Quote:
And A4 is 08FA56BC in the hit from L_AddScrollBars(), and 08394EC4 in the hit from new_app_entry(). I attached two files with the first hit from each function. I am beginning to get an idea of what is happening, even if I do not understand exactly why. I would have realized sooner if I had just looked at the top of the .c file in question earlier. This is one of the "different .c files", as I've called them in my head in lacking the means to put a more descriptive term on it. I encountered them when I was adding library based resource tracking to the code-base. They are usually CreateNewProc() or LoadSeg() but some seem unrelated to these functions (Or maybe I just have not realized the connection yet). Code in these files would fail to find the library base for my resource tracking library even if it was available everywhere SysBase or ExecBase was. And I quickly discovered that all these files start with something like: Code:
#define UtilityBase (wb_data->utility_base) #define ExecLib ((struct ExecBase *)*((ULONG *)4)) I have just now come to realize that I can refer to them as the ".c files that are unable to get correct A4 value" or "where __saveds does not really work". I get a feeling that this issue might be very specifically tied to uncommon things this code-base does. And I do not expect other people to dig trough the whole library code to find an explanation for me. So unless someone immediately recognizes this off the top of their head, from my half-explanation, I'll declare the quest for at truth of the immortal variable over. Yet again, thank you everyone for the help. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Did LEFT-Amiga M survive? | nolunchman | Amiga scene | 6 | 12 November 2018 05:25 |
Static adres | jarre | Coders. General | 5 | 24 September 2018 11:59 |
Helping Amiga love survive | elronnightshade | support.Hardware | 19 | 08 June 2010 15:21 |
Help me survive in DM - Chaos Strikes Back | NewDeli | support.Games | 18 | 19 August 2009 16:07 |
|
|