How does my static variable survive expunge?

[phx]

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

const

attribute, so the compiler can place it into the code section for PC-relative addressing.

[hceline]

Originally Posted by Thomas Richter

This is an indication that the base pointer addressing the __MERGED segment is not setup correctly in the library function that uses the static variable. Is there possibly a __saveds missing?

I tried adding __saveds to new_app_entry(), who the variable is local to, earlier. After finding that was one of few differences I could see between that, and the only other example I could find of a function-local static variable in the library code (See earlier post).

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().

Originally Posted by phx

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.

You might be right about that.
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.

Originally Posted by phx

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.

Also, since you did not read everything; I did approximately that* to solve it to begin with. This thread is me trying to solve the mystery of why this variable behaved like this in the first place. Mostly to learn from it.

*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().

Originally Posted by phx

Edit: And constant data, like your TagItem structure, should get a

const

attribute, so the compiler can place it into the code section for PC-relative addressing.

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.

[hceline]

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:

    {
        volatile char *a = 0;
        *a = 0;
    }

I found that the code that is run matches the disassembly. And that this is the right diagnostic even with __saveds:

Originally Posted by Thomas Richter

This is an indication that the base pointer addressing the __MERGED segment is not setup correctly in the library function that uses the static variable.

The library was at 08fa568c during this test.
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:

#define UtilityBase    (wb_data->utility_base)
#define ExecLib        ((struct ExecBase *)*((ULONG *)4))

And I would have to add equivalents for my resource tracking library base, where used.

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.