Re: Weak globals

Sadly, it's quite inconsistent.

This works in CRTSRVPGM:

// Compilation unit 2:

#include <stdio.h>

void foo() __attribute__((weak));
void foo()
{
printf("Foo called from compilation unit 2.\n");
}

I am able to create the service program and it looks like the symbols 
resolved correctly.  But before I test that, I tried to do CRTPGM with 
the same modules (remember that TFOO1 has a proper main).  That failed 
with CPD5D03 and the listing showed that the TFOO2 definition was being 
treated as a strong global.

So:

#pragma weak doesn't work in CRTSRVPGM or CRTPGM
__attribute__((weak)) works in CRTSRVPGM
Neither works in CRTPGM

Ugh.  I'll try the service program in a moment, just to see if calling 
routines resolve correctly.




On 4/2/2019 9:20 AM, Joe Pluta wrote:
> It looks like the #pragma weak is just not working.  Here's the 
> relevant CRTSRVPGM output:
>
> 5770SS1 V7R3M0 160422 MVXJP/TFOO    DEV       04/02
>  Module . . . . . . . . . . . : TFOO2
>    Library  . . . . . . . . . : MVXJP
>    Bound  . . . . . . . . . . : *YES
>    Change date/time . . . . . :     04/02/19 07:39:13
>    Teraspace storage enabled  : *YES
>    Storage model  . . . . . . : *SNGLVL
>        Number    Symbol      Ref 
> Identifier                                   Type      Scope Export
>        00000025  Def foo__Fv Proc      Module Strong
>        00000026  Ref         0000011C _C_SIGABRT_ctl_action Data
>
> Note that foo__Fv in TFOO2 is identified as a strong export. That's 
> just not correct.  It later conflicts with the foo__Fv from TFOO3 and 
> the service program is not created.
>
>
>
> On 4/2/2019 9:12 AM, Joe Pluta wrote:
>> Nope - still getting CPD5D03.
>>
>> On 4/2/2019 9:08 AM, Joe Pluta wrote:
>>> Thanks Jon, that's the way I'll go if I can't figure anything else 
>>> out. As you probably guess, I don't like DUPPROC, especially since 
>>> as I read the documentation, weak should work.
>>>
>>> The EXPORT(*ALL) is simply for testing, but I'm not sure how the 
>>> binder source would help.  I'm not very versed in binder source, but 
>>> as far as I can tell all binder source does is order the exported 
>>> modules.  How would it help when resolving duplicate symbols?
>>>
>>> Oh wait.  Maybe that's the problem! Maybe it's trying to export both 
>>> the weak and the strong.  Ah, let me try that.  If I add binder 
>>> source to only export main maybe that will work.
>>>
>>>
>>> On 4/2/2019 8:53 AM, Jon Paris wrote:
>>>> Joe - I think dup proc is the only way to go. As to your comment 
>>>> "and even then the order isn't _guaranteed_" that should be dealt 
>>>> with by binder language/source instead of doing Export *All.  That 
>>>> guarantees the slot sequence.
>>>>
>>>>
>>>> Jon Paris
>>>>
>>>> www.partner400.com
>>>> www.SystemiDeveloper.com
>>>>
>>>>> On Apr 2, 2019, at 8:43 AM, Joe Pluta <[email protected]> 
>>>>> wrote:
>>>>>
>>>>> Has anybody successfully used the weak #pragma for a function?  
>>>>> I'm trying to create a service program with three modules: one 
>>>>> that references a function, one with that function defined weakly, 
>>>>> and one with the function defined strongly.  In that scenario, I 
>>>>> should be able to combine the following:
>>>>>
>>>>> Reference, weak: calls weak
>>>>> Reference, strong: calls strong
>>>>> Reference, weak, strong: calls strong
>>>>> Reference only: won't compile
>>>>>
>>>>> The best example code I found was in the AIX reference:
>>>>>
>>>>> https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.0/com.ibm.xlcpp131.aix.doc/compiler_ref/prag_weak.html 
>>>>>
>>>>>
>>>>>  From what I can tell, that same syntax should work in the ILE 
>>>>> compiler, so I created the following:
>>>>>
>>>>> |// TFOO1.CPP #include <stdio.h> void foo(); int main() { foo(); } 
>>>>> // TFOO2.CPP #include <stdio.h> #pragma weak foo__Fv void foo() { 
>>>>> printf("Foo called from compilation unit 2\n"); } // TFOO3.CPP 
>>>>> #include <stdio.h> void foo() { printf("Foo called from 
>>>>> compilation unit 3\n"); } |
>>>>>
>>>>>
>>>>> CRTSRVPGM TFOO MODULES(TFOO1 TFOO2 TFOO3) EXPORT(*ALL) fails with 
>>>>> CPD5D03, Definition supplied multiple times for symbol 'foo__Fv'.
>>>>>
>>>>> I can get around it with OPTION(*DUPPROC) but then I have to be 
>>>>> very careful of the order of my modules in the MODULES keyword of 
>>>>> CRTSRVPGM (and even then the order isn't _guaranteed_).  That also 
>>>>> would hide any cases of unintentional procedure duplication, so 
>>>>> I'd really like to get #pragma weak working.
>>>>>
>>>>>
>>>>> -- 
>>>>> This is the Bare Metal Programming IBM i (AS/400 and iSeries) 
>>>>> (C400-L) mailing list
>>>>> To post a message email: [email protected]
>>>>> To subscribe, unsubscribe, or change list options,
>>>>> visit: https://lists.midrange.com/mailman/listinfo/c400-l
>>>>> or email: [email protected]
>>>>> Before posting, please take a moment to review the archives
>>>>> at https://archive.midrange.com/c400-l.
>>>>>
>>>>> Help support midrange.com by shopping at amazon.com with our 
>>>>> affiliate
>>>>> link: https://amazon.midrange.com
>>>
>>>
>>
>

-- 
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/c400-l
or email: [email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/c400-l.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com