Request: gdb 14.1 integration

[skeeto]

Thanks for the heads up. I didn't know there was a new release this past weekend. I have a seemingly-working update (b0ce23d) which required a fix to one of my patches and a workaround for a new GDB build bug. I'll need to try it out for awhile before putting it into a release, though. GDB is probably the least reliable program included in w64devkit, so I need to make sure it's in a usable state. If you want to help, build the gdb-14.1 branch yourself and give GDB a thorough test drive.

The master branch hasn't been touched in nearly three months (46e4afd), and I've been dogfooding that commit daily this whole period. That means it's in a great state for a release, so I'm going to make a new w64devkit release within the next day or so with GDB 13.1. If 14.1 behaves at least as well 13.1, it will make it into the release after this.

[skeeto]

Unfortunately I have bad news: I will need to revert to GDB 13.1. The GDB 14.1 32-bit build does not detect file changes and is barely unusable in its current state. If anyone would like to investigate, here's how you can reproduce on GDB 14.1 in the "i686" flavor:

$ cat main.c
int main(void)
{
    return 0;
}
$ cc -g3 main.c
$ gdb a.exe
Reading symbols from a.exe...
(gdb) start
`C:\Users\wellons\a.exe' has changed; re-reading symbols.
Temporary breakpoint 1 at 0x40134f: file main.c, line 3.
Starting program: C:\Users\wellons\a.exe

Thread 1 hit Temporary breakpoint 1, main () at main.c:3
warning: Source file is more recent than executable.
3           return 0;
(gdb) k
[Inferior 1 (process 93004) killed]
(gdb) !sed -i s/0/1/ main.c
(gdb) !cc -g3 main.c
(gdb) start
Temporary breakpoint 2 at 0xc31344: file main.c, line 2.
Starting program: C:\Users\wellons\a.exe

Thread 1 hit Temporary breakpoint 2, main () at main.c:3
3           return 0;
(gdb)

Note the "Source file is more recent than executable" warning (it's not), lack of "has changed; re-reading symbols" on the second run, and the stale source line. Looks like it may be caused by broken timestamp handling in this build. It does not affect GDB on 32-bit Linux, just Windows.

[Peter0x44]

GDB 14.2 has been released now. Maybe this is worth revisiting.

[skeeto]

Thanks for pointing this out, @Peter0x44. I made a gdb-14.2 branch with the upgrade, so you can try it for yourself. Unfortunately GDB 14.2 still busted on i686-w64-mingw32. I didn't report it upstream, so the GDB devs are probably unaware that it's been broken for two releases now.

[Peter0x44]

@skeeto have you reported this upstream yet, or should I do it? It seems like it won't be addressed unless that happens, there is no one regularly testing i686-w64-mingw32.

[skeeto]

I have not reported this upstream, in part because I haven't figured out how to present it in a useful way. Inability to natively build GDB on the target in question makes it a lot more complicated. So if you'd like to tackle this report, go for it!

[Peter0x44]

@skeeto if it helps to investigate any further, I had some upstream discussions:

i found the reason, gnulib/config.h does this:
#define __MINGW_USE_VC2005_COMPAT 1
which in turn enables this in _mingw.h:
#define _USE_32BIT_TIME_T
...
so bfd and gdb have different opinions what time_t really is

[Peter0x44]

bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=31636

[oscarbg]

Nice find.. seems either gdb or mingw have to agree.. in the meanwhile possibly a custom gdb patch (to conform to mingw time struct) would be fastest option to fix?

[Peter0x44]

@oscarbg you're free to try! I think commenting out the mentioned define in gnulib may work, would be good to get confirmation.

[Peter0x44]

Or alternatively, adding the define into CFLAGS manually. That sounds easier than the patch.

[skeeto]

Thanks, @Peter0x44! I've updated the gdb-14.2 branch with the CFLAGS and CXXFLAGS defines, and it seems to do the trick. It's still unclear to me why this suddenly became a problem in 14: gnulib is unchanged between 13 and 14, and 13 was already using stat.

I'll test drive GDB 14.2 for awhile, especially 32-bit, and merge if it works at least as well as 13.1.

[Peter0x44]

it's still unclear to me why this suddenly became a problem in 14

Further details are in the bug report.

[skeeto]

Thanks again, @Peter0x44. Amazing how effective it is simply to reach out and ask someone more familiar with the problem! (I need to get better at that.)

With this fix, GDB 14.2 has been working well for me today. No more hiccups. So I'll likely merge that branch soon.