Problem with 64 bit gcc 8.4 by dodicat (split from 25215)

[SARG]

@srvaldez
Some weeks ago you reported an issue with gas64 (when using ld version 2.36). I fixed it but I got this warning : ' fbextra.x contains output sections; did you forget -T?"

Recently Jeff released the modification and wrote about this message : "For the fbextra.x warning, if LD doesn't recognize the file as an object file format, it assumes it is a linker script. Will try adding the '-T' option explicitly in a separate fix."

Maybe the 2 problems are linked.

The compiler creates a section for the linker when compiling then it reuses this section when it launches the linker.

[paul doe]

I had similar issues. If you remove the export clause, it works. But then, what's the point of not exporting dll functions?

[jj2007]

If this was the PowerBASIC forum

Did you ever experience fighting with a dozen different "toolchain" setups in the PowerBASIC forum?

[deltarho[1859]]

Did you ever experience fighting with a dozen different "toolchain" setups in the PowerBASIC forum?

No, nor here for that matter. Perhaps half a dozen or so - everybody else are on ventilators.

[srvaldez]

@developers
I have a suggestion that should fix this problem, whenever the C emitter emits an asm block then have the emitter first push the gcc optimization options and set the O level to 0 then emit the asm block and finally pop the gcc optimazation options
something like this
#pragma GCC push_options
#pragma GCC optimize ("O0")
emit asm block
#pragma GCC pop_options
see https://gcc.gnu.org/onlinedocs/gcc-4.5. ... agmas.html
[edit]
or perhaps simply add volatile to the asm block https://gcc.gnu.org/onlinedocs/gcc-7.2. ... d-Asm.html

[srvaldez]

adding the pragmas doesn't make a difference for some reason, couldn't figure out how to add volatile

Code: Select all

#pragma GCC push_options
#pragma GCC optimize ("O0")
 __asm__ ( 
	".section .drectve\n"
	"\t.ascii \" -export:\\\"ISAPRIME\\\"\"\n"
);
#pragma GCC pop_options

[coderJeff]

Overall process is: BAS -> C -> ASM -> OBJ -> DLL
Appears to be a change how gcc handles ASM code injected in to the C source, or a change in binutils in how it relocates sections (ASLR? or link optimizations?) that has caused this fbc bug to appear.

fbc through gcc will write a to a special ".drectve" section in the object file to store the names of the exports.
LD reads back this section to determine the exports. This section is generated by fbc by injecting ASM directives into the C source.

fbc C emitter doesn't take any steps to close this section, so when gcc reads the ASM or LD relocates sections (I honestly don't know which or both), extra code and data that wasn't meant to be included in the .drectve section goes along for the ride and corrupts the object file when LD reads back the exports.

Seems like should be a simple enough fix. Looks like SARG already took steps to prevent this issue in gas64 emitter.

[SARG]

Looks like SARG already took steps to prevent this issue in gas64 emitter.

Not the case:
The issue was that with the/a new version of binutils 2.36 the exe is relocated at a very high address above the 32bit limit and a such instruction :
QWORD PTR ["+lname+"+rax*8]" can only handle 32bit for lname. So I just use a temporary register allowing 64 bit.

However I got also this warning : ' fbextra.x contains output sections; did you forget -T?"

And Jeff you have written about this message :

"For the fbextra.x warning, if LD doesn't recognize the file as an object file format, it assumes it is a linker script. Will try adding the '-T' option explicitly in a separate fix."

[adeyblue]

I don't know how it is in GCC, but in Visual Studio you can export functions in C either by saying so in the source code, or by providing a def file to the linker. If GCC/LD has an equvalent of a def file, then you can probably use that to export functions without marking them as such in the code and so avoid the current problem.
Or maybe not. It's just an idea, I haven't tried it

[jj2007]

by providing a def file to the linker

Same in Assembly. The format is pretty simple:

Code: Select all

LIBRARY "Name_of_dll"
EXPORTS
MyProc0
MyProc1
MyProc2

You tell the linker /DLL /DEF:Name_of_dll.def, and that's it...

[deltarho[1859]]

This issue is not specifically with gcc 8.x. 5.2 and 6.4 are OK. The problem starts with 7.4 if not before. My guess is that is starts with gcc 7.

We need to be clear about this otherwise people will shy away from 8.x which would be a shame because for exe generation 8.3 is the one to beat.

fbc needs sorting out otherwise we will be grounded on 6.4 for dlls which is not good considering that gcc 11 is in development.

[deltarho[1859]]

In the other thread dodicat wrote:

Hi srvaldez, I tried O1, O2, O3, -Ofast with gcc 8.1 (64 bit 1.07.3) and 8.4.(from the WinFBE Editor -- 1.07.1)
No dll, just a straight compile a .bas file.
Problem--

I had no problems and neither did srvaldez.

[dodicat]

Remember that my code has export tagged to the function (as for a dll)
My command line:
fbc -Wc -O3 (or O2) (or O1) (don't want the dll yet)
WinFBE suite uses:
fbc64.exe -m <file.bas>-v -Wc -O3 -x <file.exe>
So I suggested using a different ide for the test.

[coderJeff]

From Embedded function calls

32-bit & 64-bit 1.07.1

5.2 warning .drectve -> No
6.4 warning .drectve -> No
7.4 warning .drectve -> Yes
7.5 warning .drectve -> Yes
8.3 warning .drectve -> Yes
8.4 warning .drectve -> Yes
9.2 warning .drectve -> Yes
9.3 warning .drectve -> Yes

Issue may well have started with gcc 7.0 and is clearly not a 8.x issue only.

fbc needs to check the gcc version and act accordingly; although a 'fix' may not upset gcc 5 or 6.

[coderJeff]

I've been working towards gcc 8.x on a win 10 computer and avoiding any earlier versions.

gcc 7.1 on a win 7 computer seems ok.
gcc 8.1 on a win 10 computer and I can reproduce the issue.

Even though the ASM block that fbc emits is at the end of the C listing, gcc moves the block around when optimizations are enabled.

If you look at the first few lines of the ASM that gcc makes:
from gcc 7.1:

Code: Select all

	.file   "isaprime.c"
	.intel_syntax noprefix
/APP
	.section .drectve
	.ascii " -export:\"ISAPRIME\""
/NO_APP
	.text
	.p2align 4,,15
	.globl	ISAPRIME
	.def	ISAPRIME;	.scl	2;	.type	32;	.endef

from gcc 8.1

Code: Select all

	.file	"isaprime.c"
	.intel_syntax noprefix
	.text
/APP
	.section .drectve
	.ascii " -export:\"ISAPRIME\""
/NO_APP
	.p2align 4,,15
	.globl	ISAPRIME
	.def	ISAPRIME;	.scl	2;	.type	32;	.endef

A subtle difference - in gcc-8.1 code becomes part of the export information.

I have a simple fix for this and just need to do some testing.