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.
Static link time on X86
-
volkerhalle
- Valued Contributor
- Posts: 89
- Joined: Fri Aug 14, 2020 11:31 am
- Reputation: 0
- Status: Offline
-
mgdaniel
Topic author - Active Contributor
- Posts: 34
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
- Status: Offline
- Contact:
Re: Static link time on X86
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:
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.
Added in 9 hours 22 minutes 28 seconds:
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.is it worth your time to try to run a PRIME_SIEVE.C test ?
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
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.
-
mgdaniel
Topic author - Active Contributor
- Posts: 34
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
- Status: Offline
- Contact:
Re: Static link time on X86
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
Digital Personal WorkStation with 1 CPU and 1536MB running VMS V8.4-2L1
BXNUC10i7FNH4 6 core i7 1.10GHz 32GB
innotek GmbH VirtualBox with 2 CPU and 7680MB running VMS V9.2
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
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.
And the same X86 modules not built against SSL.
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?
Time to escalate this to VSI Engineering via the Service Portal.
Thanks for all input.
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
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
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
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
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
Code: Select all
Sesola123.OBJ;1 33 29-JAN-2023 13:16
Sesola321.OBJ;1 33 29-JAN-2023 13:16
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-2L3Thanks for all input.
-
mgdaniel
Topic author - Active Contributor
- Posts: 34
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
- Status: Offline
- Contact:
Re: Static link time on X86
VSI Engineering addressed the issue promptly, saying
andThe 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.
...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.
-
mgdaniel
Topic author - Active Contributor
- Posts: 34
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
- Status: Offline
- Contact:
Re: Static link time on X86
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.
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.
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.
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
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
-
duncanmorris
- Visitor
- Posts: 1
- Joined: Fri Feb 17, 2023 6:35 am
- Reputation: 0
- Status: Offline
Re: Static link time on X86
I concur with your observations.
I link stunnel builds against the SSL OLBs and see the same performance hit with "Write program segments:"
Hopefully the new linker gets into V9.2-1
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
-
mgdaniel
Topic author - Active Contributor
- Posts: 34
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
- Status: Offline
- Contact:
Re: Static link time on X86
Thinking about my earlier comment (yet) again
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)".
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.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.
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
-
mgdaniel
Topic author - Active Contributor
- Posts: 34
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
- Status: Offline
- Contact:
Re: Static link time on X86
As an exercise I decided to build the latest OpenSSL 3.0.8 using the native X86 C compiler
with the indigenous
and the most recent X86 DECset MMS tool
which did seem intended to be for some earlier version of V9.2 and required a kludge
but seemed to do the job.
It produced a working
which when copied into the SSL3 nomenclature
produced a much more reasonable object library size,
and associated static link time
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.
Code: Select all
VSI C X7.4-726 (GEM 50X23) on OpenVMS x86_64 V9.2
Code: Select all
perl 5, version 34, subversion 0 (v5.34.0) built for VMS_x86_64
Code: Select all
VSI X86VMS DECSET V13.0-1
VSI X86VMS MMS V4.0-4
Code: Select all
X86VMS$ type SYS$SYSROOT:[SYSMGR]X86_XTOOLS$SYLOGIN.COM
$ xcc = "cc"
It produced a working
Code: Select all
OpenSSL 3.0.8 7 Feb 2023 (0x30000080) vms-x86_64 OSSL$DATAROOT:[000000]
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
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
-
jreagan
- VSI Expert
- Contributor
- Posts: 15
- Joined: Tue Dec 01, 2020 8:40 am
- Reputation: 0
- Status: Offline
Re: Static link time on X86
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.
-
mgdaniel
Topic author - Active Contributor
- Posts: 34
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
- Status: Offline
- Contact:
Re: Static link time on X86
Yes, the X86 files do seem to be noticeably larger.
Though nowhere near those of the cross-compiled.
This is the result of the suggested analysis on an Itanium stub file, showing the final symbol, 14.
And this is the equivalent X86 object file, again the final symbol is 14 (though differently sorted?)
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
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.
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
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
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
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