(Linux/Mac) update gcc to 12.2.0

[BartmanAbyss]

The binaries were built using the existing CI scripts locally on my Mac and in a Debian VM. I'm still not 100% clear why this solved the multiple of 4 error, but I'll try to get to the bottom of this and get them building correctly in Github Actions.

Originally posted by @grahambates in https://github.com/BartmanAbyss/vscode-amiga-debug/issues/133#issuecomment-1291186682

Any updates on this? I just updated the windows version of gcc to 12.2.0 and modified the CI scripts but I'm not sure if the MacOS build runs correctly now.

[grahambates]

I've checked and the binaries output from the CI job on Github are still exhibiting the same error on my Mac. As before the same CI scripts executed locally work fine. I'm really going to try to figure out what the difference is between the environments. For now I could open a PR with my locally built files, but it would be really good to get the automation working.

[BartmanAbyss]

Yeah I agree. Please open the PR. Would be great to get the CI working.

[BartmanAbyss]

BTW I also updated binutils-gdb.

[grahambates]

Ok, slight face/palm moment. I've realised that the reason my local build wasn't getting the error is because gcc-barto.patch hadn't been applied! This means that the current build doesn't have any of your optimisations 😟 . This would probably explain the poor results that girv was seeing over on EAB when comparing profiling compared to bebbo's version. Sorry about this!

The part of the patch which breaks things is this:

-/* Before the prologue, the top of the frame is at 4(%sp).  */
-#define INCOMING_FRAME_SP_OFFSET 4
+/* Before the prologue, the top of the frame is at 4(%sp), except in interrupt handlers: 6(%sp)  */
+#define DEFAULT_INCOMING_FRAME_SP_OFFSET 4
+#define INCOMING_FRAME_SP_OFFSET (m68k_get_function_kind(current_function_decl) == m68k_fk_interrupt_handler ? 6 : 4)

This results in the error:

Error: register save offset not a multiple of 4

And I mean it's right, 6 isn't a multiple of 4, but I'm not sure why it only complains about this on Mac/Linux and not Windows.

I'll see if I can dig into this, but in the meantime I have a working build with the rest of the patch applied.

[BartmanAbyss]

I could only find this error text in binutils-gdb/gas/dw2gencfi.c in cfi_add_CFA_offset and cfi_add_CFA_val_offset. It refers to DWARF2_CIE_DATA_ALIGNMENT which is declared in gas/config/tc-m68k.h as -4. However I'm not sure if we can simply change that. That 6 is only used in interrupt handlers, which is used in the template project static __attribute__((interrupt)) void interruptHandler().

[grahambates]

Yeah I found the same thing:

gas/dw2gencfi.c

  abs_data_align = (DWARF2_CIE_DATA_ALIGNMENT < 0
            ? -DWARF2_CIE_DATA_ALIGNMENT : DWARF2_CIE_DATA_ALIGNMENT);
  if (offset % abs_data_align)
    as_bad (_("register save offset not a multiple of %u"), abs_data_align);

gas/config/tc-m68k.h

#define DWARF2_CIE_DATA_ALIGNMENT (-4)

Any thoughts on why this isn't an issue on Windows?

[BartmanAbyss]

not really. maybe i can try to make a minimal repro to debug.

[grahambates]

I can try changing it to -2 and see what happens

[grahambates]

So far so good just changing the constant. The template project builds and runs with the fully patched GCC. I'll do some more testing and if we decide to go ahead with this I'll add the patch to the CI scripts.

[BartmanAbyss]

to check if it works as intended, you could set breakpoints in regular functions and interrupt handlers and see if you get a valid callstack.

[grahambates]

Yeah that breaks the ability to set breakpoints in regular functions!

[BartmanAbyss]

maybe it only needs fixing in tc_m68k_frame_initial_instructions (void) (tc-m68k.c)? still investigating..

[BartmanAbyss]

try ..\..\bin\win32\opt\m68k-amiga-elf\bin\readelf.exe --debug=frames a.elf >a.frames from template/out. My windows build looks like this a.frames.txt Interestingly enough it shows Data alignment factor: -2, I think that should be DWARF2_CIE_DATA_ALIGNMENT which apparently is 4 under Linux.

[grahambates]

I'm getting:

  Code alignment factor: 2
  Data alignment factor: -4

vs yours:

  Code alignment factor: 1
  Data alignment factor: -2

[BartmanAbyss]

is this with DWARF2_CIE_DATA_ALIGNMENT = -2 or -4?

[grahambates]

This is the unmodified version, so -4.

With the broken version where I set DWARF2_CIE_DATA_ALIGNMENT to -2, I get:

  Code alignment factor: 2
  Data alignment factor: -2

[BartmanAbyss]

I made a simple repro. Check src\test\suite\data\gcc\item.*. There are major differences between win32 and linux in the output item.s, namely it seems in the windows build gcc creates DWARF-v1 info directly via .byte, .long (so independent of gas) , but the linux version creates DWARF-3 info via .cfi_* commands (that get processed by gas) This leads me to believe that the windows version doesn't even care about the gas/dw2gencfi and gas/config/tc-m68k files, thus not outputting that error message (it comes from gas, not gcc) I even let gcc dump its spec files, but am not sure I see anything relevant in the output files.

Here are the outputs of the both test scripts for win32 and linux out.zip

[grahambates]

Ok that makes sense. I was really puzzled how gas was behaving differently on Windows.

I suppose the options are:

• Get GCC to output .byte / .long data on Mac/Linux too
• Patch gas to handle the .cfi_* commands correctly

[BartmanAbyss]

This is different: Linux: checking assembler for cfi directives... yes Windows: configure:24512: checking assembler for cfi directives | configure:24586: result: no Ofcourse on the windows build the linux can't find m68k-amiga-elf-as as it's built for windows. So, maybe we can simulate that behavior on Linux & Mac by not installing binutils and gcc into the same directory so gcc also doesn't find the assembler.

[grahambates]

Ok I'll give that a try. We need to make sure it doesn't use the native Mac/Linux as though.

[BartmanAbyss]

Or any other way to override autoconf's config.in/config.h

/* Define 0/1 if your assembler supports CFI directives. */
#undef HAVE_GAS_CFI_DIRECTIVE

/* Define 0/1 if your assembler supports .cfi_personality. */
#undef HAVE_GAS_CFI_PERSONALITY_DIRECTIVE

/* Define 0/1 if your assembler supports .cfi_sections. */
#undef HAVE_GAS_CFI_SECTIONS_DIRECTIVE

[BartmanAbyss]

Ok I'll give that a try. We need to make sure it doesn't use the native Mac/Linux as though.

here's the CI log output: checking for as... /home/runner/work/vscode-amiga-debug/vscode-amiga-debug/output/m68k-amiga-elf/bin/as checking where to find the target as... pre-installed in /home/runner/work/vscode-amiga-debug/vscode-amiga-debug/output/m68k-amiga-elf/bin

so probably works. maybe easiest is to just wait with the binutils-install script until after gcc has been built?

[grahambates]

yeah I'll try just changing the order of the scripts

[BartmanAbyss]

I just pushed the changed order and will test when the CI build is finished.

[BartmanAbyss]

This would be the other way of disabling .cfi: flag_dwarf2_cfi_asm = 0; ^_^ https://gcc.gnu.org/legacy-ml/gcc-patches/2008-09/msg01915.html

[grahambates]

I think changing the build order works. I'm now wondering whether I really did forget to patch GCC orignally. There's a chance I actually just built them this way round.

[BartmanAbyss]

yep, looks good now. will update linux/mac binaries.

[BartmanAbyss]

hmm.. there's no gdb...

[grahambates]

libtool: install: `/Users/runner/work/vscode-amiga-debug/vscode-amiga-debug/output/bin/m68k-amiga-elf-gdb' is not a directory

[BartmanAbyss]

yeah, make install works, but make install-strip doesn't. currently debugging. what a mess.

[BartmanAbyss]

I'm too dumb for linux.

[grahambates]

I think I can see what's wrong with the command. It's the way the STRIPPROG env var is prefixed to the install command.

/bin/sh ./libtool --mode=install STRIPPROG='strip' /bin/sh /Users/runner/work/vscode-amiga-debug/vscode-amiga-debug/binutils-gdb/install-sh -c -s \
            gdb \
            /Users/runner/work/vscode-amiga-debug/vscode-amiga-debug/output/bin/$transformed_name ;

The arg that comes immediately after libtool --mode=install needs to be a command.

On the other ones that work correctly it looks like this:

STRIPPROG='strip' /bin/sh ./libtool   --mode=install /bin/sh /Users/runner/work/vscode-amiga-debug/vscode-amiga-debug/binutils-gdb/install-sh ...

[grahambates]

I have a fix for this. I'll open a PR on your binutils fork. It looks like this is broken upstream.

[grahambates]

I'm too dumb for linux.

or perhaps the binutils/gdb maintainers are 😉

[BartmanAbyss]

Thanks. that helped, but now: next problem. Seems binutils is no longer statically linked. When I tried it on my office PC I just get:

barto@barto10:~$ /mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb
/mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.33' not found (required by /mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb)
/mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.32' not found (required by /mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb)
/mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.34' not found (required by /mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb)

Which seems to make sense as the CI scripts run on Ubuntu 22, and here I have Ubuntu 20. Still, the old version worked, so somehow static linkage of all binutils binaries seem to have disappeared. Any ideas? (btw: gcc still works)

OLD:

ldd /mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb
        not a dynamic executable

NEW:

ldd /mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb2
/mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb2: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb2)
/mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb2: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb2)
/mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb2: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /mnt/c/Users/barto/Documents/Visual_Studio_Code/vscode-amiga-debug/bin/linux/opt/bin/m68k-amiga-elf-gdb2)
        linux-vdso.so.1 (0x00007fffee7c2000)
        libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007ffc56270000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007ffc56240000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007ffc56210000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007ffc561e0000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffc56091000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffc55e90000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ffc56c4b000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffc55e5d000)

[grahambates]

I'll have a look. Either I did something different but didn't update the CI script or it's related to the binutils upgrade. I'll figure it out.

[grahambates]

Quick update on this:

• The glib version is linked to the GCC version you compile with. We can get better compatibility by using gcc-9, which we already do for the gcc build.
• The lack of static linking was triggered by the update to binutils. The CI scripts haven't changed and were previously outputting static binaries.
• I can't see anything obviously wrong with the build. As far as I can see the LDFLAGS var including the -static option is getting passed to the linking command.

I'll continue investigating...

[grahambates]

It looks like it's no longer possible to make a completely static gdb binary. If force it then I get a bunch of warnings and a resulting binary that segfaults.

We can still make it portable though. I've addressed the glib compatibility and removed dependencies on some of the linked libraries by disabling options.

    --without-expat \
    --without-zstd \
    --without-lzma \

The remaining ones are all system libaries that should be safe to rely on.

[BartmanAbyss]

Thanks. Interestingly enough, the windows version still is static - I only had to hack a bit with libwinpthread.dll.a ^_^