gdb TUI?

[Trass3r]

Any reason for not enabling the text UI with --enable-tui? :)

[FreddieChopin]

There is no reason on my side (; However please note that gdb's TUI actually IS enabled automatically when your system has suitable libraries available (I would say that this would be at least curses, but maybe something else too). If you don't explicitly say --enable-tui or --disable-tui, then ./configure detects whether you have what is needed or not. In here arm-none-eabi-gdb -tui works fine. If it doesn't work for you, then it means that you don't have all required components in the system and the script (as it is right now) would fail with an error if you would force-enable TUI with --enable-tui.

$ ldd ~/arm-none-eabi-gcc-9.1.0-190503/bin/arm-none-eabi-gdb
    linux-vdso.so.1 (0x00007ffc75dad000)
    libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007f3faac15000)
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f3faac10000)
    libpython3.7m.so.1.0 => /usr/lib/libpython3.7m.so.1.0 (0x00007f3faa898000)
    libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f3faa85e000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f3faa83d000)
    libutil.so.1 => /usr/lib/libutil.so.1 (0x00007f3faa838000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f3faa6f0000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f3faa52b000)
    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f3fab3c2000)
$ ls -l /lib/*curses*
lrwxrwxrwx 1 root root     13 01-11 09:45 /lib/libcurses.so -> libncurses.so
-rw-r--r-- 1 root root     18 01-11 09:45 /lib/libcursesw.so
-rw-r--r-- 1 root root     20 01-11 09:45 /lib/libncurses++.so
-rw-r--r-- 1 root root     18 01-11 09:45 /lib/libncurses.so
lrwxrwxrwx 1 root root     18 01-11 09:45 /lib/libncurses++w.so -> libncurses++w.so.6
lrwxrwxrwx 1 root root     16 01-11 09:45 /lib/libncursesw.so -> libncursesw.so.6
lrwxrwxrwx 1 root root     20 01-11 09:45 /lib/libncurses++w.so.6 -> libncurses++w.so.6.1
lrwxrwxrwx 1 root root     18 01-11 09:45 /lib/libncursesw.so.6 -> libncursesw.so.6.1
-rwxr-xr-x 1 root root  71456 01-11 09:45 /lib/libncurses++w.so.6.1
-rwxr-xr-x 1 root root 449040 01-11 09:45 /lib/libncursesw.so.6.1

As GDB is built at the very end, a failure there is very painful, especially for people with slower machines, where the script can take several hours to complete (I've had reports that it takes up to 3 hours for some people).

Do you think this behaviour should be changed? Or maybe this should just be documented in the README.md? Or do you have some completely different idea?

[Trass3r]

I was just curious, as -tui prints not supported on Windows. Guess it's more complicated to get curses working in this cross-compilation scenario. By the way I also tested https://github.com/cyrus-and/gdb-dashboard but it crashes gdb-py.

[FreddieChopin]

I was just curious, as -tui prints not supported on Windows.

Well, for Windows you would need some *curses* too, like libpdcurses.dll. Getting this library is not a big problem, but there's a question whether GDB's configure script will accept this library and whether GDB will work with it at all... If you think this is worthwhile, either you or me could try to explore this path and see whether it works or not.

By the way I also tested https://github.com/cyrus-and/gdb-dashboard but it crashes gdb-py.

On Windows I guess, right? This may be a problem that on Windows arm-none-eabi-gdb-py.exe is built with Python 2, which you actually have to install on your system manually and add it to PATH. First make sure you can actually use arm-none-eabi-gdb-py.exe at all, in a normal scenario. Then you could try this pyton TUI. It's possible that this TUI needs Python 3, and this would be a problem, because last time I tried you cannot build GDB with Python support for Windows using Python 3 - only Python 2 was supported /; Maybe this changed now (it probably will have to change some time in the future), but maybe not.

[Trass3r]

Yeah it did pick up some python2 dll from my path but crashed deep in the call stack after returning to the exe. The readme says it uses Py2. Py3 seems to be tricky at least: https://github.com/gnu-mcu-eclipse/arm-none-eabi-gcc-build/issues/2

[FreddieChopin]

Py3 seems to be tricky at least: gnu-mcu-eclipse/arm-none-eabi-gcc-build#2

So nothing changed and you still cannot build GDB for Windows with Python 3.

Yeah it did pick up some python2 dll from my path but crashed deep in the call stack after returning to the exe.

Could you please try to use exactly the same version that was used to compile the toolchain (python-2.7.16)?

[Trass3r]

As GDB is built at the very end, a failure there is very painful

Tell me about it, finally tried the script myself. I wish it were more "incremental-friendly", skipping downloads, extract, cleanup and build steps that have already succeeded. Especially because I keep getting weird errors about missing headers files etc that go away when running it again, probably make parallelism related.

So far I help myself with some if false; then blocks and

+   if [ ! -f "${1}" ]; then
    curl -L -o ${1} -C - --connect-timeout 30 -Y 1024 -y 30 ${2} || ret=$?

[FreddieChopin]

So far I help myself with some if false; then blocks and

Seems like a good fix, but imagine what happens if your download is broken, for example it got stuck in the middle, the server disconnected and now you have half of that file on your disk? (; The real fix would be to verify the downloads with a checksum or with a signature, but this was not done yet.

Actually in here the re-downloads take almost no time compared to the rest of the script, maybe 10 seconds?

I wish it were more "incremental-friendly", skipping downloads, extract, cleanup and build steps that have already succeeded.

This is more complicated than it appears on the first sight. Mostly because it's hard to tell that the step was completed successfully when running the script again and because when one step fails there is a need to actually "roll-back" to the last successful checkpoint. Once you get over all of the initial hurdles, the script runs successfully 99% of times you try it, so the incentive to implement something like that is much lower then...

Especially because I keep getting weird errors about missing headers files etc that go away when running it again, probably make parallelism related.

Post them here or in a separate bug report. I have a machine with 8 logical threads and never saw anything like that (the build is obviously parallel where possible).

BTW - even if you skip documentation, GDB now seems to require makeinfo anyway, so make sure you actually have it installed.

BTW 2 - if you're using ubuntu, the README.md has a list of things which were required on a clean system some time ago.

BTW 3 - to try a faster build, you can run the script like this ./build-bleeding-edge-toolchain.sh --skip-documentation --skip-nano-libraries. Once this works fine, you can proceed to building the full toolchain (please keep in mind that documentation required texinfo and texlive!).

[Trass3r]

Seems like a good fix, but imagine what happens if your download is broken, for example it got stuck in the middle, the server disconnected and now you have half of that file on your disk? (; The real fix would be to verify the downloads with a checksum or with a signature, but this was not done yet.

Well the extract should fail then.

Actually in here the re-downloads take almost no time compared to the rest of the script, maybe 10 seconds?

Try that in Asia.

This is more complicated than it appears on the first sight.

Yep I would simply add a few more skip parameters to the script. --skip-native, --skip-gdb, --skip-strip etc.

BTW - even if you skip documentation, GDB now seems to require makeinfo anyway, so make sure you actually have it installed.

Yes, I saw the fix: https://github.com/nolange/bleeding-edge-toolchain/commit/72e08a323308c2080f1446850a6b6be64ca25727 Actually using quite a few of his patches already. They should go upstream eventually.

BTW 2 - if you're using ubuntu, the README.md has a list of things which were required on a clean system some time ago.

An actual apt-get commandline would be more helpful. I installed sudo apt-get install -y build-essential g++ g++-mingw-w64 autoconf automake libtool bison flex gettext curl xz-utils p7zip-full

BTW 3 - to try a faster build, you can run the script like this ./build-bleeding-edge-toolchain.sh --skip-documentation --skip-nano-libraries. Once this works fine, you can proceed to building the full toolchain (please keep in mind that documentation required texinfo and texlive!).

I've been building --enable-win64 --keep-build-folders --skip-documentation.

[FreddieChopin]

Well the extract sould fail then.

It will, but this whole discussion started about errors which are reported later instead of as early as possible (;

Try that in Asia.

It says Germany in your profile, sorry for wrong assumptions (; How long does the re-download of everything take for you?

Actually using quite a few of his patches already. They should go upstream eventually.

Some of them were incorporated. Others can be provided as pull-requests (;

I've been building --enable-win64 --keep-build-folders --skip-documentation.

Like I've said - once the script works without nano libraries, you can then enable them with no issues. The build of nano libraries almost doubles the time it takes for the script to finish, so it's a good thing to skip for a start, while you're sorting out the issues.

An actual apt-get commandline would be more helpful.

If I would be using Ubuntu, I would surely post it, but I'm using Arch so I really have no idea what is required on Ubuntu apart from the info in README.md, which was contributed by Ubuntu user some time ago. Sorry for that );

[Trass3r]

Well, for Windows you would need some *curses* too, like libpdcurses.dll. Getting this library is not a big problem, but there's a question whether GDB's configure script will accept this library and whether GDB will work with it at all...

It's not that complicated in the end. Download from http://ftp.gnu.org/pub/gnu/ncurses/ and build. But I had to set the build triple explicitly or it wouldn't properly detect the cross-compilation scenario, very weird: ./configure --build=x86_64-pc-linux-gnu --host=x86_64-w64-mingw32 --enable-term-driver --enable-sp-funcs --prefix=pwd/../install

Then amend CPPFLAGS and LDFLAGS in buildGdb() to find it.

[Trass3r]

The build of nano libraries almost doubles the time it takes for the script to finish, so it's a good thing to skip for a start, while you're sorting out the issues.

btw why do you have to build gcc again for nano, just for the -print-multi-lib?

[FreddieChopin]

btw why do you have to build gcc again for nano, just for the -print-multi-lib?

I don't have a definitive answer. I did it exactly the same way as ARM does their original toolchain. Note that "nano" libraries is not only the gcc build - its all of gcc libraries (including libstdc++) and also whole newlib. I guess the time to build gcc itself is not that significant here - most of the time is taken by building the libraries anyway - there are 20 variants of them (;

[Trass3r]

Yeah I've been using --disable-multilib --with-arch=armv7e-m --with-mode=thumb --with-float=soft for testing because of that.