Created attachment 13727 [details] build errors I built on MSYS2/MinGW64 environment, with the following commands: ../configure --enable-64-bit-bfd --disable-werror --disable-win32-registry --disable-rpath --with-curses --enable-targets=all make -j4 Errors are attached.
Created attachment 13728 [details] Partial fix patch With the attached patch, most of the errors are solved. There are still a few errors in sim/erc32/func.c.
Created attachment 13729 [details] Errors after patch errors-2.log are with my patch applied.
I forgot to mention I also had to revert a5884035977f95b09c28d4bb2276ac4869930e96 because readline is not defined.
Why? What led to the broken? Bake delicious cakes and own yourself many famous cookie chains: https://cookieclicker3.com
These all seem to be sim-specific, so I'm changing the component. You can try --disable-sim to bypass this, unless you specifically need the simulator.
i build all the sims with: --enable-targets=all --enable-gdb --enable-sim --host=i686-w64-mingw32 and they're working for me now. you didn't say the exact target you're using to compile here. that output looks like it's running on Windows, but i'm not familiar with the error messages generated. is that a GNU assembler ? C:\Users\orgads\AppData\Local\Temp\cco9NQ8A.s: Assembler messages: C:\Users\orgads\AppData\Local\Temp\cco9NQ8A.s:208: Error: value of 0000001000000339 too large for field of 4 bytes at 00000000000000f9 the LPSIZE error messages suggest you're using an out-of-date source tree. please make sure you have the latest git before trying to build anything.
I wrote that I build on MSYS2/MinGW64. I tried with latest git (gdb-11-branch), but got the same result. Anyway, I don't need the simulators. I'll try to disable them. Thanks for the tip. This is just a workaround though, the full build should be fixed.
The reason for the LPSIZE errors is that for some reason #include "../config.h" in defs.h picks a file named config.h in mingw/include instead of sim/config.h, so all the HAVE_* macros are not defined. I addressed this particular issue by replacing it with ../../sim/config.h. See my patch.
(In reply to Orgad Shaneh from comment #7) > latest git (gdb-11-branch) use the latest master branch, not gdb-11-branch
Created attachment 13732 [details] errors on master errors-master.log is on latest master, with only this patch applied: diff --git a/sim/common/defs.h b/sim/common/defs.h index 8bf129943ae..379c865967d 100644 --- a/sim/common/defs.h +++ b/sim/common/defs.h @@ -36,7 +36,7 @@ /* Include common sim's various configure tests. */ #ifndef SIM_COMMON_BUILD -#include "../config.h" +#include "../../sim/config.h" #else #include "config.h" #endif
not sure why you're changing the config.h path. the search paths should be such that only the sim one is located. the sim is cross-compiling for me using current toolchain projects: cross-i686-w64-mingw32/binutils-2.37_p1 cross-i686-w64-mingw32/gcc-11.2.0 cross-i686-w64-mingw32/mingw64-runtime-8.0.0 feel free to dig into those CPP errors more to see why they're showing up for you the getline ones are obvious. we aren't building gnulib for the build system, only the host, so tools we compile for the build system fail. that said, getline is in POSIX now, so it sounds like maybe the mingw you're building against needs fixing (and is worth filing a bug for them). no idea about the assembler errors. looks like a Windows thing.
Ok, the config.h patch was not needed. I did need to add some eol=lf entries in .gitattribute. Some sim still fail on sim-utils.c. I'll attach the updated error log.
Created attachment 13734 [details] errors on master - clean
the log unfortunately is not sufficient to dive into because the compiler isn't providing enough diagnostics. focus on one failure at a time. for example, go into sim/mips/ and run `make V=1`. look at the first failure (hopefully sim-utils.c), then take the compiler invocation and change the -c to -E -dD, and run it by hand. it should hopefully produce a better error message. if that works, look at the .o file it created (which you should rename to .i) and try to see what it is complaining about.
Thank you very much. I compared the preprocessed output on debian and on Windows, and found out that the real errors are actually in winnt.h. gcc doesn't give much information on this case indeed. Patch [1] fixes most of the compilation issues, except the strange assembly error and missing getline. Patch [2] fixes some compiler warnings on erc32, but the assembly errors still appear. [1] https://sourceware.org/pipermail/gdb-patches/2021-October/182851.html [2] https://sourceware.org/pipermail/gdb-patches/2021-October/182852.html
Created attachment 13735 [details] errors after patches on master
both your patches have been merged now. do you "just" have linker errors now ? all the compile-time issues have been resolved ? not sure how to get the linker to emit more information.
Created attachment 13749 [details] verbose assembly of erc32/func.c Regarding getline, shouldn't it be provided by gnulib? MinGW is not POSIX. The errors that I still have are these: F:/git-sdk-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: opc2c.o: in function `main': F:/Projects/binutils-gdb/sim/m32c/opc2c.c:541: undefined reference to `getline' and the assembly errors. They are not link-time, but compile-time errors. I attached a verbose assembly of the file. These are the errors for this file: func.s:2241: Error: value of 0000001000001e8d too large for field of 4 bytes at 000000000000134d func.s:2308: Error: value of 0000001000001f69 too large for field of 4 bytes at 0000000000001429 func.s:2336: Error: value of 0000001000001fc0 too large for field of 4 bytes at 0000000000001480 func.s:2349: Error: value of 0000001000001ff0 too large for field of 4 bytes at 00000000000014b0 func.s:2351: Error: value of 0000001000001ff8 too large for field of 4 bytes at 00000000000014b8 func.s:2505: Error: value of 00000010000021d1 too large for field of 4 bytes at 0000000000001691 func.s:2724: Error: value of 0000001000002471 too large for field of 4 bytes at 0000000000001931 func.s:2748: Error: value of 00000010000024b9 too large for field of 4 bytes at 0000000000001979 func.s:2753: Error: value of 00000010000024c9 too large for field of 4 bytes at 0000000000001989 func.s:2756: Error: value of 00000010000024d4 too large for field of 4 bytes at 0000000000001994 func.s:2948: Error: value of 0000001000002736 too large for field of 4 bytes at 0000000000001bf6 func.s:3002: Error: value of 00000010000027db too large for field of 4 bytes at 0000000000001c9b func.s:3036: Error: value of 000000100000284b too large for field of 4 bytes at 0000000000001d0b func.s:3114: Error: value of 0000001000002947 too large for field of 4 bytes at 0000000000001e07 func.s:3237: Error: value of 0000001000002adc too large for field of 4 bytes at 0000000000001f9c func.s:3278: Error: value of 0000001000002b65 too large for field of 4 bytes at 0000000000002025 func.s:3951: Error: value of 00000010000032e2 too large for field of 4 bytes at 0000000000002792 func.s:3958: Error: value of 0000001000003305 too large for field of 4 bytes at 00000000000027ad func.s:4757: Error: value of 0000001000003907 too large for field of 4 bytes at 0000000000002ec7 func.s:4767: Error: value of 000000100000392d too large for field of 4 bytes at 0000000000002ee5
Mike, can you please push also https://sourceware.org/pipermail/gdb-patches/2021-October/182836.html ?
(In reply to Orgad Shaneh from comment #18) > Regarding getline, shouldn't it be provided by gnulib? we currently only build gnulib for the --host system, not --build. so we are providing gnulib too --host, but these are --build tools which don't help. > MinGW is not POSIX. i'll note that MinGW literally means "Minimalist GNU for Windows". getline was a GNU extension that made it into POSIX. the logical thing really is for MinGW to support the latest POSIX and include GNU extensions. but i don't know when upstream MinGW is going to get around to that, and we try to build GNU sim on more than POSIX systems. would be nice if we figured out how to build & use gnulib for --build too > I attached a verbose assembly of the file. These are the errors for this > file: > func.s:2241: Error: value of 0000001000001e8d too large for field of 4 bytes > at 000000000000134d i'm thinking this is a bug in either gcc or the assembler, but prob gcc. so this should get reported to the gcc folks. > https://sourceware.org/pipermail/gdb-patches/2021-October/182836.html that touches top-level files which needs someone to review that. i suspect the answer isn't to force line encodings, so you'll prob want to file a dedicated bug if the gas manual is failing to build under Windows. for the sim parts, i pushed a fix for igen instead: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f0982318065617e92c28e23ee382981c2a898ca2
(In reply to Mike Frysinger from comment #20) > but i don't know when upstream MinGW is going to get around to that, and we > try to build GNU sim on more than POSIX systems. would be nice if we > figured out how to build & use gnulib for --build too hmm, we could cheat for now. if not cross-compiling (which i think is what you're doing), we could assume that --build & --host are compatible and thus link in the gnulib for --host into the --build tools too. i have a patch pending that is blocking some build tool clean up work: https://sourceware.org/pipermail/binutils/2021-October/118363.html once that is merged, and i can flush these sim build patches, i can look at trying out the gnulib-when-not-cross-compiling idea for the sim.
Both issues are still unresolved in 12.1.
I read the backlog, and I'm confused on the --build vs --host discussion. OOC, what are these --build tools you refer to? > func.s:4767: Error: value of 000000100000392d too large for field of 4 bytes at 0000000000002ee5 This sounds like the kind of error you could get by using "long" to store a 64-bit value -- long is always 32-bit on Windows, even on 64-bit Windows. Maybe a bug like that in the assembler?
(In reply to Orgad Shaneh from comment #22) > Both issues are still unresolved in 12.1. it's unclear what you mean by "both issues". you've reported a lot of things in here, many of which are fixed. we should just close this and you can file new bugs with just one issue in each bug.
Undefined reference to getline in m32c, and bad assembly in erc32. I'll file new bugs for these.
Filed bug 30882. Sorry for the long delay...
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=acaf48b921453c37fc2df4151699c912940bcd25 commit acaf48b921453c37fc2df4151699c912940bcd25 Author: Orgad Shaneh <orgads@gmail.com> Date: Sun Mar 3 12:22:14 2024 +0200 sim/erc32: Rename EVENT_MAX -> MAX_EVENTS EVENT_MAX is defined as 0x7FFFFFFF (INT_MAX) in winuser.h, so when building on Windows, the value is overridden and compilation fails because the array size of evbuf is too large. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28476 Approved-By: Tom Tromey <tom@tromey.com>