On Sun, 6 Aug 2017, JonY via Mingw-w64-public wrote:

On 08/05/2017 09:14 PM, Martin Storsjö wrote:
This helps finding unimplemented functions; otherwise the symbol
will exist, but won't contain any implementation, so the function
will end up pointing at whatever other function the linker places

I would prefer these checks be in the autoconfigury layer where:

...blah blah test...
        [arm32], [AC_DEFINE(USE_ARM32_MATH)],
        [arm64], [...]
        [AC_MSG_ERROR([Unsupported platform])

That way, we don't need to keep growing the if/else macros as more
platforms are added.

Consider also using AM_CONDITIONAL and other automake constructs if
they're separate files to be compiled.

I'm not sure I think this is somthing that would help with the issue I'm trying to address here - I think that kinda misses the point.

We already have things similar to that; we have a custom list of files to build into libmingwex.a for each of the 4 architectures, so if desired, we could easily split these assembly files into one for each architecture as well.

Currently there's code for x86 (32 and 64 bit) and 32 bit arm in the same file. The consistent next step would be to add 64 bit arm into the same (see patch 09/19) - in most cases, it's just a few 2-5 instruction snippets so it's much less overhead to add to the same file instead of creating completely new ones. If you want to, we could also split them into separate files for each architecture.

Currently, these source files are under this heading in Makefile.am:

# These mingwex sources are target independent:
  crt/dllentry.c        crt/dllmain.c \

Having configure error out if you build for a new unsupported architecture, would help a user trying to build for another new, unsupported architecture, to know that it's pointless to proceed.

However, if you're the one trying to implement support for that new architecture, the first thing you'd need to do is to update configure.ac and add the new architecture to the list of "supported" ones, in order to even configure the build. And then what?

Then you need to provide all the necessary functions for the platform. In order to do that, you'd most probably start off with the source files for one of the existing architectures (in my case, I took the list of source files for arm32), read each and every one of the files manually and see which of them need customizations for the new arch.

The "read each file manually" step is something I think most programmers would avoid and just go ahead and try compiling things - that's what I did.

I took the list of source files for arm32 and tried building for arm64, and fixed issues until it all built without errors and mostly without warnings.

Some files would have an explicit #error that's easy to spot, and fix. Some files would implicitly try building e.g. x86 assembly, and fail.

For some other case, you might have a function completely missing, which you'd notice when you try to link an app that uses that function.

But the deal with these assembly file, that is so devious, is that it assembles without error, and it even defines the symbol, but without actually producing any code. If I had gotten linker errors about missing symbols, or assembler errors or preprocessor errors, it would have been obvious to spot the issue.

On the other hand, I see almost all other asm files also have the same issue. The other ones (stdio/scanf*.S) I had already noticed, since the rest of the associated code clearly errored out and pointed out all of those functions to me.

// Martin
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Mingw-w64-public mailing list

Reply via email to