946
Applications / Re: OS/4 (technical details only)
« on: March 11, 2019, 10:15:02 pm »
No. The FIRST variable in a section is aligned. But not necessarily the ones that follow.
OS2World.com Forum is back !!!
Remember to visit OS2World at:
http://www.os2world.com
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Only the FIRST variable in the section is aligned to the desired alignment.The others need to be aligned manually.
Lars,
ff_cos_32 defined in C, what is defined in asm right now is aligned ok
You Need to define all segments as public. Only then will they combine.
They are declared as public. The weird thing is the various types of text segments. From the map file,Code: [Select]Segment Class Group Address Size
======= ===== ===== ======= ====
TEXT32 CODE CGROUP 0001:00000000 009fe590
________TEXT CODE CGROUP 0001:009fe590 00000000
text CODE AUTO 0002:00000000 000ca2cb
DATA32 DATA DGROUP 0003:00000000 0001d990
Aout gives,Code: [Select]TEXT32 CODE CGROUP 0001:00000000 00bd1560
________TEXT CODE CGROUP 0001:00bd1560 00000000
DATA32 DATA DGROUP 0002:00000000 00015a20
Note that the DGROUP ends up in segment 0003.
The other question is, does it matter?
Same error.You Need to define all segments as public. Only then will they combine.
Anyways there are bigger problems, still using 64kb segments, lots of missing symbols for some reason, perhaps lost when the code is bigger then the segment, inconsistent underline prefix (I just hacked the code to fix for us, changing an ifdef to ifndef). Too many segments.
Here's a map file.
OK, we have a workaround, namely building with --disable-AVX.
Now we're just left with the question of why our toolchain is not aligning these AVX instructions. It only seems to be a problem in libavcodec/x86/fft.asm.
One possibility is a weakness in the AOUT format. I vaguely remember problems getting things to work as can be seen by this from libavutil/x86/x86inc.asmCode: [Select]; aout does not support align=
; NOTE: This section is out of sync with x264, in order to
; keep supporting OS/2.
%macro SECTION_RODATA 0-1 16
%ifidn __OUTPUT_FORMAT__,aout
SECTION .text
%elifidn __OUTPUT_FORMAT__,coff
SECTION .text
%elifidn __OUTPUT_FORMAT__,win32
SECTION .rdata align=%1
%elif WIN64
SECTION .rdata align=%1
%else
SECTION .rodata align=%1
%endif
%endmacro
IIRC, one problem is that aout only supports text segments and is quite primitive compared to newer object formats.
Perhaps I should port the whole build system to using obj (OMF32) format.
Background, aout is an ancient object format that was once common.
Our GCC was forked a long time back and still outputs aout object code. Generally we then use emxomf at link time to convert to native omf and use the system linker to create executables.
Currently in FFmpeg, nasm outputs aout, which is also converted to omf at link time.
We can also convert GCC object files at build time, which would also allow nasm to output omf or obj as nasm calls it.
Obj also needs the FLAT and USE32 parameters to create 32 bit code as it was originally a 16 bit format.
Problem is testing as I don't have AVX hardware.
Hi David, that crash looks like one I get now and again, I believe font related.
Have you tested with the Firefox build that OS4USER mentioned? Perhaps with the AVX enabled kernel? You can get a list of CPU capabilities with this program, http://hobbes.nmsu.edu/download/pub/os2/util/misc/cpuinfo.zip
If needed, I could build FFmpeg with AVX disabled. Be nice to know which function it is crashing in too.
Thanks for all the responses.
I just installed the noAVX kernel and my traps have disappeared. This is just preliminary but I have no problem going to that web site and others so far. So far, so good.
My avcode56.dll is the same size and date on both my ArcaOS 5.02 and ArcaOS 5.03 partitions.
Attached a pic of my type of CPU info. While modifying this message, I had another trap which I have attached. I just remembered that this is another instance when a trap occurred. However, so far, this one trap is all I have encountered so far with the noAVX.