Static link time on X86

OpenVMS x86 Field Test questions, reports, and feedback.
User avatar

volkerhalle
Master
Posts: 196
Joined: Fri Aug 14, 2020 11:31 am
Reputation: 0
Status: Offline

Re: Static link time on X86

Post by volkerhalle » Fri Jan 27, 2023 8:35 am

Mark,

I had used the newer one (2.0c) from http://wwwhomes.uni-bielefeld.de/achim/prime_sieve.c and just added:

#ifndef __VAX
#define true_64bit_words
#endif
#define _ANSI_EXTENSION
#ifndef __VAX
typedef __int64 int64;
typedef unsigned __int64 uint64;
#endif

I just ran it for 10^9 (P1 = 1000000000) and 10^10 (P1 = 10000000000) and noted the run-time.

Volker.


Topic author
mgdaniel
Valued Contributor
Posts: 62
Joined: Mon Feb 28, 2022 5:16 pm
Reputation: 0
Location: Adelaide, South Australia
Status: Offline
Contact:

Re: Static link time on X86

Post by mgdaniel » Fri Jan 27, 2023 8:58 am

Looks like it will take a while. Likely I'll get back to you tomorrow (my time).

Added in 9 hours 22 minutes 28 seconds:
is it worth your time to try to run a PRIME_SIEVE.C test ?
I repurposed the link time procedure and found had to suppress <stdout> from the executable or it took forever and generated lots of spurious EXEC, KERNEL, etc. usage.

Code: Select all

$ set noverify
$ set noon
$ sec1 = f$cvtime(,,"secondofyear")
$ cpu1 = f$getjpi(0,"cputim")
$ dio1 = f$getjpi(0,"dirio")
$ flt1 = f$getjpi(0,"pageflts")
$ define /user sys$output nl:
$ mcr []prime_sieve.exe 1000000000
$ sec2 = f$cvtime(,,"secondofyear")
$ cpu2 = f$getjpi(0,"cputim")
$ dio2 = f$getjpi(0,"dirio")
$ flt2 = f$getjpi(0,"pageflts")
$ write sys$output "elapsed:", sec2 - sec1, " cpu:", cpu2 - cpu1, -
                   " dirio:", dio2 - dio1, " pageflts:", flt2 - flt1
These MONITOR values were obtained /AVERAGE some time after beginning and represent some 2 minutes of processing (less on the Itanium).

HP rx2660 (1.40GHz/6.0MB) with 4 CPU and 14335MB running VMS V8.4-2L3

$ @sieve_time.com
elapsed:80 cpu:7980 dirio:5 pageflts:79

CPU Busy 100%
User Mode 100%
Idle Time 299%

Digital Personal WorkStation with 1 CPU and 1536MB running VMS V8.4-2L1

$ @sieve_time.com
elapsed:354 cpu:34991 dirio:5 pageflts:85

CPU Busy 99%
User Mode 100%
Idle Time 0%

BXNUC10i7FNH4 6 core i7 1.10GHz 32GB
innotek GmbH VirtualBox with 2 CPU and 7680MB running VMS V9.2

$ @sieve_time.com
elapsed:146 cpu:14621 dirio:4 pageflts:86

CPU Busy 85%
Interrupt State 3%
Kernel Mode 35%
User Mode 54%
Idle Time 108%

Dell Optiplex 9020 SFF i7-4770 QC 3.4Ghz 16GB Windows 10 Pro
innotek GmbH VirtualBox with 2 CPU and 7574MB running VMS V9.2

$ @sieve_time.com
elapsed:295 cpu:29471 dirio:4 pageflts:99

CPU Busy 101%
Interrupt State 1%
Kernel Mode 38%
User Mode 62%
Idle Time 99%

The interesting aspect of these data is the complete absence of higher mode activity on the hardware, in comparison to the X86 VMs.


Topic author
mgdaniel
Valued Contributor
Posts: 62
Joined: Mon Feb 28, 2022 5:16 pm
Reputation: 0
Location: Adelaide, South Australia
Status: Offline
Contact:

Re: Static link time on X86

Post by mgdaniel » Sun Jan 29, 2023 5:24 pm

In a personal email (not forum post) it was suggested examining the linker map statistics to see where the elapsed and CPU time might be being spent. Sure enough, there are standout values with the two X86 systems. Item of note is ^^^^^ underscored.

HP rx2660 (1.40GHz/6.0MB) with 4 CPU and 14335MB running VMS V8.4-2L3

Code: Select all

Performance Indicators                            Page Faults   CPU Time        Elapsed Time
----------------------                            -----------   --------        ------------
    Command processing:                                    62   00:00:00.04     00:00:00.19
    Pass 1:                                              1801   00:00:00.32     00:00:01.92
    Allocation/Relocation:                                 19   00:00:00.01     00:00:00.04
    Pass 2:                                              2849   00:00:00.61     00:00:01.23
    Write program segments:                                16   00:00:00.00     00:00:00.22
                                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Symbol table output:                                  557   00:00:00.01     00:00:00.01
    Map data after object module synopsis:                 15   00:00:00.23     00:00:00.24
Total run values:                                        5319   00:00:01.22     00:00:03.87
Digital Personal WorkStation with 1 CPU and 1536MB running VMS V8.4-2L1

Code: Select all

Performance Indicators                            Page Faults   CPU Time        Elapsed Time
----------------------                            -----------   --------        ------------
    Command processing:                                   143   00:00:00.29     00:00:00.47
    Pass 1:                                               279   00:00:01.85     00:00:01.98
    Allocation/Relocation:                                 76   00:00:00.10     00:00:00.11
    Pass 2:                                               773   00:00:01.66     00:00:02.11
    Map data after object module synopsis:                 13   00:00:00.44     00:00:00.45
                                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Symbol table output:                                    0   00:00:00.00     00:00:00.01
Total run values:                                        1284   00:00:04.34     00:00:05.14
BXNUC10i7FNH4 6 core i7 1.10GHz 32GB
innotek GmbH VirtualBox with 2 CPU and 7680MB running VMS V9.2

Code: Select all

Performance Indicators                            Page Faults   CPU Time        Elapsed Time
----------------------                            -----------   --------        ------------
    Command processing:                                    37   00:00:00.10     00:00:00.09
    Pass 1:                                             16886   00:00:00.92     00:00:00.94
    Allocation/Relocation:                                 65   00:00:00.00     00:00:00.00
    Pass 2:                                             11098   00:00:00.72     00:00:00.78
    Write program segments:                               351   00:02:10.41     00:02:10.50
                                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Symbol table output:                                  576   00:00:00.02     00:00:00.02
    Map data after object module synopsis:                 17   00:00:00.37     00:00:00.37
Total run values:                                       29030   00:02:12.54     00:02:12.75
Dell Optiplex 9020 SFF i7-4770 QC 3.4Ghz 16GB Windows 10 Pro
innotek GmbH VirtualBox with 2 CPU and 7574MB running VMS V9.2

Code: Select all

Performance Indicators                            Page Faults   CPU Time        Elapsed Time
----------------------                            -----------   --------        ------------
    Command processing:                                    38   00:00:00.22     00:00:00.23
    Pass 1:                                             17696   00:00:02.99     00:00:03.84
    Allocation/Relocation:                                106   00:00:00.01     00:00:00.02
    Pass 2:                                             11008   00:00:02.33     00:00:02.90
    Write program segments:                               355   00:15:36.44     00:20:32.81
                                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Symbol table output:                                  581   00:00:00.06     00:00:00.13
    Map data after object module synopsis:                235   00:00:00.66     00:00:00.92
Total run values:                                       30019   00:15:42.71     00:20:40.91
Seems as if a lot of X86 linker time and effort is being expended writing program segments (whatever that means exactly). But it's obviously not just writing to storage.

It was further suggested that this might reflect the object modules themselves. I had previously noticed some seemed disproportionately large. Here are a couple of shim objects from Itanium and the equivalent from X86.

Code: Select all

Sesola123_SSL.OBJ;1            5  29-JAN-2023 13:09
Sesola321_SSL.OBJ;1            5  29-JAN-2023 13:09

Sesola123_SSL.OBJ;1          847  29-JAN-2023 13:08
Sesola321_SSL.OBJ;1          847  29-JAN-2023 13:08
And the same X86 modules not built against SSL.

Code: Select all

Sesola123.OBJ;1               33  29-JAN-2023 13:16
Sesola321.OBJ;1               33  29-JAN-2023 13:16
Seems as those built against SSL (e.g. #include "openssl/ssl.h") are very large in comparison to their Itanium (and Alpha) counterparts. All those not built against SSL are (within architectural considerations and non-optimising (x)compiler of comparable size.

Is there something amiss with the X86 (x)compiler in that it is including all (SSL) symbols in the object module, or something like this, all of which then must be resolved/processed, (unnecessarily?) chewing CPU and elapsed time?

Code: Select all

VSI C X7.4-547 (GEM 50V6F) for X86 on OpenVMS IA64 V8.4-2L3
Time to escalate this to VSI Engineering via the Service Portal.

Thanks for all input.


Topic author
mgdaniel
Valued Contributor
Posts: 62
Joined: Mon Feb 28, 2022 5:16 pm
Reputation: 0
Location: Adelaide, South Australia
Status: Offline
Contact:

Re: Static link time on X86

Post by mgdaniel » Tue Jan 31, 2023 12:04 pm

VSI Engineering addressed the issue promptly, saying
The following is not meant as a -solution- to your situation, rather it’s going to be input to the optimization and performance processing of the linker once the compiler team gets that far.

First remember that the native linker is built with a compiler that doesn’t optimize. It is felt that it shouldn’t be the only cause of the apparent slow-down, however.

Next, the linker uses a simple sort algorithm to sort the search table in the frame headers ( .eh_frame_hdrxx). When linking a test program against the SSL object library, it shows the search table is bigger than expected, thus proving the simple sort algorithm to be -too- simple. It’s very likely that one of the next linker versions will have a better sort algorithm, possibly qsort() from the CRTL.

It’s not currently understood -why- the search table is so big. It appears the linker is being forced to include more modules from the SSL object library than on other platforms. One thought is there may be more code with more unwind data generated for X86. The difference in size of the object modules may be an indicator of that. Further, this may be caused by the non-optimizing compilers.

We checked the build’s linker maps for the same performance statistics as you presented, and found only three instances of elapsed time greater than 10 seconds. Unfortunately, none of these images links with the SSL object library; the SSL shareable images are used. The build of the SSL sharable images is not part of the VMS OS build so there are no map files to examine.

So, no immediate solution other than linking against the SSL shareable, but we appreciate your having brought this to our attention; there may be some relief in the next linker version, but i can’t promise that it will be part of the upcoming V9.2-1 release.
and
...tests of the newest internal linker appears to have alleviated the slowdown... I’ll be checking if that linker will make it into V9.2-1.


Topic author
mgdaniel
Valued Contributor
Posts: 62
Joined: Mon Feb 28, 2022 5:16 pm
Reputation: 0
Location: Adelaide, South Australia
Status: Offline
Contact:

Re: Static link time on X86

Post by mgdaniel » Wed Feb 15, 2023 11:38 pm

With native compiler VSI C X7.4-726 (GEM 50X23) on OpenVMS x86_64 V9.2 available the object files are a much more expected size. Here are the same couple of shim objects reported on earlier, from cross-compiled X86 code, followed by native compiled code.

Code: Select all

Sesola123_SSL.OBJ;1      847  29-JAN-2023 13:08
Sesola321_SSL.OBJ;1      847  29-JAN-2023 13:08

SESOLA123_SSL.OBJ;1.      18  16-FEB-2023 09:21
SESOLA321_SSL.OBJ;1.      18  16-FEB-2023 09:21
Big difference!

Seems to have made a (barely) noticeable difference in static link time though. First is linking cross-compiled object code, second native compiled.

Code: Select all

%ILINK-I-THREADUPCALLS, user thread upcalls automatically enabled
elapsed:972 cpu:97076 dirio:4848 pageflts:28837

%ILINK-I-THREADUPCALLS, user thread upcalls automatically enabled
elapsed:836 cpu:83488 dirio:4812 pageflts:28250
Perhaps a native compiled X86 linker (with suggested improved sort algorithm) will do the trick. When linking it appears to be entirely (well mostly-entirely) USER mode.


duncanmorris
Visitor
Posts: 2
Joined: Fri Feb 17, 2023 6:35 am
Reputation: 0
Status: Offline

Re: Static link time on X86

Post by duncanmorris » Fri Feb 17, 2023 6:57 am

I concur with your observations.
I link stunnel builds against the SSL OLBs and see the same performance hit with "Write program segments:"

IA64 stunnel link
Write program segments: 71 00:00:00.00 00:00:00.25
X86_64 stunnel link
Write program segments: 333 00:01:12.77 00:01:13.02

Hopefully the new linker gets into V9.2-1


Topic author
mgdaniel
Valued Contributor
Posts: 62
Joined: Mon Feb 28, 2022 5:16 pm
Reputation: 0
Location: Adelaide, South Australia
Status: Offline
Contact:

Re: Static link time on X86

Post by mgdaniel » Fri Feb 17, 2023 11:40 am

Thinking about my earlier comment (yet) again
With native compiler VSI C X7.4-726 (GEM 50X23) on OpenVMS x86_64 V9.2 available the object files are a much more expected size.
Now that we have a native X86 compiler, It will be interesting to see the relative sizes of a native-built VSI SSL (and there will be one soon after the recent "OpenSSL Security Advisory [7th February 2023]"). The current releases have obviously been cross-compiled because the object libraries show similar bloat.

Code: Select all

SSL111$LIBCRYPTO.OLB;1          15597  14-DEC-2022 12:28
SSL111$LIBCRYPTO32.OLB;1        15564  14-DEC-2022 12:18
SSL111$LIBSSL.OLB;1              3314   6-DEC-2022 17:52
SSL111$LIBSSL32.OLB;1            3341   6-DEC-2022 16:57

SSL111$LIBCRYPTO.OLB;1         232267  10-DEC-2022 13:30:48.71
SSL111$LIBCRYPTO32.OLB;1       233079  10-DEC-2022 12:34:53.66
SSL111$LIBSSL.OLB;1             30581   6-DEC-2022 23:40:28.24
SSL111$LIBSSL32.OLB;1           30722   6-DEC-2022 20:20:32.68
No second-guesses to what order these are presented in. Build location (Itanium) confirmed by the X86 SSL reporting itself as "OpenSSL 1.1.1s 1 Nov 2022 (0x1010113F) vms-ia64-p32 SSL111$ROOT:[000000]" having been built on Itanium; highlight derived from "OpenSSL_version (OPENSSL_PLATFORM)".


Topic author
mgdaniel
Valued Contributor
Posts: 62
Joined: Mon Feb 28, 2022 5:16 pm
Reputation: 0
Location: Adelaide, South Australia
Status: Offline
Contact:

Re: Static link time on X86

Post by mgdaniel » Tue Feb 21, 2023 9:00 am

As an exercise I decided to build the latest OpenSSL 3.0.8 using the native X86 C compiler

Code: Select all

VSI C X7.4-726 (GEM 50X23) on OpenVMS x86_64 V9.2
with the indigenous

Code: Select all

perl 5, version 34, subversion 0 (v5.34.0) built for VMS_x86_64
and the most recent X86 DECset MMS tool

Code: Select all

VSI X86VMS DECSET V13.0-1
VSI X86VMS MMS V4.0-4
which did seem intended to be for some earlier version of V9.2 and required a kludge

Code: Select all

X86VMS$ type SYS$SYSROOT:[SYSMGR]X86_XTOOLS$SYLOGIN.COM
$ xcc = "cc"
but seemed to do the job.

It produced a working

Code: Select all

OpenSSL 3.0.8 7 Feb 2023 (0x30000080) vms-x86_64 OSSL$DATAROOT:[000000]
which when copied into the SSL3 nomenclature

Code: Select all

Directory SYS$COMMON:[SSL3.LIB]

SSL3$LIBSSL32.OLB;2
                           4485  21-FEB-2023 17:11:16.04
SSL3$LIBSSL32.OLB;1
                          20854  10-NOV-2022 16:57:34.67

SSL3$LIBCRYPTO32.OLB;2
                          32874  21-FEB-2023 17:10:43.39
SSL3$LIBCRYPTO32.OLB;1
                         211493  10-NOV-2022 16:45:51.41
produced a much more reasonable object library size,

and associated static link time

Code: Select all

X86VMS$ @LINK_TIME.COM
%ILINK-I-THREADUPCALLS, user thread upcalls automatically enabled
elapsed:4 cpu:465 dirio:5959 pageflts:8321
This strongly suggests any improved native linker sort algorithm will have a minimal impact on static link time, and that the current behaviour is largely a result of the exaggerated file size (and underlying whatever) of the cross-compiled object files.


jreagan
VSI Expert
Master
Posts: 134
Joined: Tue Dec 01, 2020 8:40 am
Reputation: 0
Status: Offline

Re: Static link time on X86

Post by jreagan » Tue Feb 21, 2023 9:42 am

While the code size is smaller, I think the symbol tables are still very large. ANAL/OBJ/SECTION=SYMTAB can show the number of symbols.


Topic author
mgdaniel
Valued Contributor
Posts: 62
Joined: Mon Feb 28, 2022 5:16 pm
Reputation: 0
Location: Adelaide, South Australia
Status: Offline
Contact:

Re: Static link time on X86

Post by mgdaniel » Tue Feb 21, 2023 2:02 pm

Yes, the X86 files do seem to be noticeably larger.

Code: Select all

IA64$ dir /width=filename=24 SYS$COMMON:[SSL3.LIB]SSL3$*32.OLB

Directory SYS$COMMON:[SSL3.LIB]

SSL3$LIBCRYPTO32.OLB;1         26135  14-DEC-2022 16:46
SSL3$LIBSSL32.OLB;1             3894  14-DEC-2022 16:52

Total of 2 files, 30029 blocks.

Code: Select all

X86VMS$ dir /width=filename=24 SYS$COMMON:[SSL3.LIB]SSL3$*32.OLB

Directory SYS$COMMON:[SSL3.LIB]

SSL3$LIBCRYPTO32.OLB;2         32874  21-FEB-2023 17:10:43.39
SSL3$LIBCRYPTO32.OLB;1        211493  10-NOV-2022 16:45:51.41
SSL3$LIBSSL32.OLB;2             4485  21-FEB-2023 17:11:16.04
SSL3$LIBSSL32.OLB;1            20854  10-NOV-2022 16:57:34.67

Total of 4 files, 269706 blocks.
Though nowhere near those of the cross-compiled.

Code: Select all

Directory WASD_ROOT:[src.httpd.obj_ia64]
Sesola123_SSL.OBJ;1                5  24-JAN-2023 07:27

Directory WASD_ROOT:[src.httpd.obj_x86_64]
SESOLA123_SSL.OBJ;1               18  21-FEB-2023 14:48:56.91

Directory DKA100:[WASD_ROOT_230108.src.httpd.obj_x86_64]
sesola123_ssl.obj;1              847  11-DEC-2022 08:49:22.23
This is the result of the suggested analysis on an Itanium stub file, showing the final symbol, 14.

Code: Select all

8< snip 8<
FileAddr Offset in Section 10. (000A)
-------- ----------------------------
00000500 00000150  Symbol 14. (0000000E)          "SSL_get1_peer_certificate"
00000500 00000150    Name Index in Sec. 9.:              00000079     121.
00000504 00000154    Symbol Info Field:                        12                                       symtab$b_st_info
                       Symbol Type:                            02          STT_FUNC
                       Symbol Binding:                         01          STB_GLOBAL
00000505 00000155    Symbol 'Other' Field:                     80                                       symtab$b_st_other
                       Symbol Visibility                       00          STV_DEFAULT
                       Linkage Type                            80          VMS_STL_STD
00000506 00000156    Bound to section:                       0000       0. (SHDR$K_SHN_UNDEF)           symtab$w_st_shndx
00000508 00000158    Symbol Value                0000000000000000       0.                              symtab$pq_st_value
00000510 00000160    Size associated with sym:   0000000000000000                                       symtab$q_st_size

8< snip 8<
Analyze Object File                          22-FEB-2023 05:14:48.71                                                   Page 9
WASD_ROOT:[src.httpd.obj_ia64]Sesola123_SSL.OBJ;1
ANALYZ I01-55

The analysis uncovered NO errors.

ANAL/OBJ/SECTION=SYMTAB WASD_ROOT:[SRC.HTTPD.OBJ_IA64]SESOLA123_SSL.OBJ
And this is the equivalent X86 object file, again the final symbol is 14 (though differently sorted?)

Code: Select all

8< snip 8<
Analyze Object File                          22-FEB-2023 05:18:43.23                                                   Page 7
WASD_ROOT:[src.httpd.obj_x86_64]SESOLA123_SSL.OBJ;1
ANALYZ X01-85

FileAddr Offset in Section 19. (0013)
-------- ----------------------------
00001B18 00000108  Symbol 11. (0000000B)          "SSL_get1_peer_certificate"
00001B18 00000108    Name Index in Sec. 1.:              00000093     147.
00001B1C 0000010C    Symbol Info Field:                        10                                       symtab$b_st_info
                       Symbol Type:                            00          STT_NOTYPE
                       Symbol Binding:                         01          STB_GLOBAL
00001B1D 0000010D    Symbol 'Other' Field:                     00                                       symtab$b_st_other
                       Symbol Visibility                       00          STV_DEFAULT
00001B1E 0000010E    Bound to section:                       0000       0. (SHDR$K_SHN_UNDEF)           symtab$w_st_shndx
00001B20 00000110    Symbol Value                0000000000000000       0.                              symtab$pq_st_value
00001B28 00000118    Size associated with sym:   0000000000000000                                       symtab$q_st_size

00001B30 00000120  Symbol 12. (0000000C)          "SSL_get_peer_certificate"
00001B30 00000120    Name Index in Sec. 1.:              0000007A     122.
00001B34 00000124    Symbol Info Field:                        12                                       symtab$b_st_info
                       Symbol Type:                            02          STT_FUNC
                       Symbol Binding:                         01          STB_GLOBAL
00001B35 00000125    Symbol 'Other' Field:                     00                                       symtab$b_st_other
                       Symbol Visibility                       00          STV_DEFAULT
00001B36 00000126    Bound to section:                       0004       4. "$CODE$"                     symtab$w_st_shndx
00001B38 00000128    Symbol Value                0000000000000040      64.                              symtab$pq_st_value
00001B40 00000130    Size associated with sym:   0000000000000014                                       symtab$q_st_size

00001B48 00000138  Symbol 13. (0000000D)          "ToLowerCase"
00001B48 00000138    Name Index in Sec. 1.:              000000AD     173.
00001B4C 0000013C    Symbol Info Field:                        11                                       symtab$b_st_info
                       Symbol Type:                            01          STT_OBJECT
                       Symbol Binding:                         01          STB_GLOBAL
00001B4D 0000013D    Symbol 'Other' Field:                     00                                       symtab$b_st_other
                       Symbol Visibility                       00          STV_DEFAULT
00001B4E 0000013E    Bound to section:                       FFF2   65522. (SHDR$K_SHN_COMMON)          symtab$w_st_shndx
00001B50 00000140    Symbol Value                0000000000000004       4.                              symtab$pq_st_value
00001B58 00000148    Size associated with sym:   0000000000000004                                       symtab$q_st_size

00001B60 00000150  Symbol 14. (0000000E)          "ToUpperCase"
00001B60 00000150    Name Index in Sec. 1.:              000000B9     185.
00001B64 00000154    Symbol Info Field:                        11                                       symtab$b_st_info
                       Symbol Type:                            01          STT_OBJECT
                       Symbol Binding:                         01          STB_GLOBAL
00001B65 00000155    Symbol 'Other' Field:                     00                                       symtab$b_st_other
                       Symbol Visibility                       00          STV_DEFAULT
00001B66 00000156    Bound to section:                       FFF2   65522. (SHDR$K_SHN_COMMON)          symtab$w_st_shndx
00001B68 00000158    Symbol Value                0000000000000004       4.                              symtab$pq_st_value
00001B70 00000160    Size associated with sym:   0000000000000004                                       symtab$q_st_size

8< snip 8<
Analyze Object File                          22-FEB-2023 05:18:43.25                                                   Page 8
WASD_ROOT:[src.httpd.obj_x86_64]SESOLA123_SSL.OBJ;1
ANALYZ X01-85

The analysis uncovered NO errors.

ANAL/OBJ/SECTION=SYMTAB WASD_ROOT:[SRC.HTTPD.OBJ_X86_64]SESOLA123_SSL.OBJ
Is there any particular field in the ELF header I should be quoting for symbol table size? My lay interpretation says they contain the same number of symbols.

The cross-compiled equivalent object file had considerably more symbols.

Code: Select all

8< snip 8<
Analyze Object File                          22-FEB-2023 05:11:44.22                                                   Page 352
DKA100:[WASD_ROOT_230108.src.httpd.obj_x86_64]sesola123_ssl.obj;1
ANALYZ X01-85

FileAddr Offset in Section 27. (001B)
-------- ----------------------------
0003B1D8 00008268  Symbol 1391. (0000056F)          "SSL_get1_peer_certificate"
0003B1D8 00008268    Name Index in Sec. 28.:             00007ABA   31418.
0003B1DC 0000826C    Symbol Info Field:                        10                                       symtab$b_st_info
                       Symbol Type:                            00          STT_NOTYPE
                       Symbol Binding:                         01          STB_GLOBAL
0003B1DD 0000826D    Symbol 'Other' Field:                     00                                       symtab$b_st_other
                       Symbol Visibility                       00          STV_DEFAULT
0003B1DE 0000826E    Bound to section:                       0000       0. (SHDR$K_SHN_UNDEF)           symtab$w_st_shndx
0003B1E0 00008270    Symbol Value                0000000000000000       0.                              symtab$pq_st_value
0003B1E8 00008278    Size associated with sym:   0000000000000000                                       symtab$q_st_size

0003B1F0 00008280  Symbol 1392. (00000570)          "_GLOBAL_OFFSET_TABLE_"
0003B1F0 00008280    Name Index in Sec. 28.:             00007AFC   31484.
0003B1F4 00008284    Symbol Info Field:                        10                                       symtab$b_st_info
                       Symbol Type:                            00          STT_NOTYPE
                       Symbol Binding:                         01          STB_GLOBAL
0003B1F5 00008285    Symbol 'Other' Field:                     00                                       symtab$b_st_other
                       Symbol Visibility                       00          STV_DEFAULT
0003B1F6 00008286    Bound to section:                       0000       0. (SHDR$K_SHN_UNDEF)           symtab$w_st_shndx
0003B1F8 00008288    Symbol Value                0000000000000000       0.                              symtab$pq_st_value
0003B200 00008290    Size associated with sym:   0000000000000000                                       symtab$q_st_size

8< snip 8<
Analyze Object File                          22-FEB-2023 05:11:44.24                                                   Page 353
DKA100:[WASD_ROOT_230108.src.httpd.obj_x86_64]sesola123_ssl.obj;1
ANALYZ X01-85

The analysis uncovered NO errors.

ANAL/OBJ/SECTION=SYMTAB DKA100:[WASD_ROOT_230108.src.httpd.obj_x86_64]SESOLA123_SSL.OBJ

Post Reply