Experiences with gdb elf

[mikrosk]

This is not a bug report, just a "thread" to collect experiences (ok and bugs ;)) with our gdb. I wrote to both @vinriviere and @th-otto (I wasn't sure whom to ask ;-)) for an executable: Thorsten had a newer one (built in October) while Vincent had one from August.

Vincent's worked fine but Thorsten's, whoa, that was yet another level! Without installing anything, just having TosWin2 + gdb executable I immediately got colors. I've tried so far:

• stepping over instructions
• stepping over source code (with manual source code path setting, cool stuff!)
• breakpoints

Everything worked all right, except:

• the stairs effect on quitting gdb (when having a program running)

So I'd say, pretty good, pretty good. If you have other things worth mentioning, feel free to do so (in case of more complex bugs or if too many of them we can create separate issues).

[vinriviere]

Haha, I initially disabled the colors to avoid trouble. With that old gdb binary, colors can be enabled manually with set style enabled on. No more required with current sources, as I reverted the color settings to default (colors on).

And indeed, stepping into sources is really pleasant. You can also try disas. Be sure to test the tui mode with gdb --tui my.tos. Or enable it manually while already inside gdb with Ctrl+X+A.

NB: I didn't encounter any stairs effect. When quitting a program, I see a line Inferior 1 .. will be killed. As I understand, that's expected indentation, not a stairs bug.

[mikrosk]

Ha! You are correct. Your executable doesn't seem to exhibit the stairs effect: While Thorsten's does:

[th-otto]

Interesting. I can only assume that this is due to different ncurses/readline libraries being used. The only patch i remember there is https://github.com/th-otto/rpmint/blob/master/patches/readline/readline-mint.patch, but this should be active in the version i used (and also applied to the readline library of binutils https://github.com/th-otto/binutils/blob/8b0530c0176e461d94644ddbd26a1148c51d7ba2/readline/readline/terminal.c#L703-L706)

Which version did you use @vinriviere ?

[vinriviere]

I build gdb from that branch : https://github.com/freemint/m68k-atari-mint-binutils-gdb/commits/gdb-mintelf-vri

That's work in progress. I should have forked the repository to my private space, instead of creating a branch there. Anyway, when it's mature, I will squash/rework the commits and push them to the official mintelf branch.

I remember there was a stairs effect long ago. I fixed it that way: https://github.com/freemint/m68k-atari-mint-binutils-gdb/commit/e98a051459fc382767a1473742ba126a687d777c I believe this is the right way, because MiNT doesn't support different CRNL/NLCR translation for input and output.

BTW, I use an unpatched ncurses 6.4, and IIRC the readline shipped with binutils/gdb.

[th-otto]

I build gdb from that branch :

That probably means it was using the bundled version of readline.

I fixed it that way: e98a051

Uh, buts that's a bug in mint definitely. Those settings are only meant for input, and should not affect output.

But indeed, after applying that patch, stairs effects are gone in my version. I've rebuild the readline library, and also applied the official patches from https://ftp.gnu.org/pub/gnu/readline/readline-7.0-patches/

[th-otto]

There is one issue which i just found when trying to debug GEM programs: when the application calls wind_update(BEG_UPDATE), the console window hangs when toswin calls wind_update() to update the screen. Any idea how that can be solved?

Edit: One solution could be, to simply ignore wind_update() calls of traced programs. That can result in those programs writing to foreign windows/the desktop, but would atleast prevent such lockups. What do you think?

--- a/xaaes/src.km/xa_wind.c
+++ b/xaaes/src.km/xa_wind.c
@@ -1895,6 +1895,12 @@ XA_wind_update(int lock, struct xa_client *client, AESPB *pb)
    else
        p = get_curproc();

+   if (p->ptracer)
+   {
+       DIAG((D_sema, NULL, "'%s:wind_update(0x%x) ignored for traced program", p->name, op));
+       return XAC_DONE;
+   }
+
    switch (op & 0xff)
    {

[mikrosk]

Similar (and maybe more compatible?) approach could be forcing the NO_BLOCK flag in case of a traced program?

[th-otto]

No, that won't help. That flag would only prevent the application from being blocked. But it is the terminal window that is blocked later when you reenter gdb.

[th-otto]

Another issue: if some library function crashes, gdb does not seem to able to display a correct backtrace:

On x86, that seems to work more reliable, even if functions were compiled with -fomit-framepointer. Haven't checked yet how gdb tries to get those backtraces.

One solution could be to link against libc_g.a instead of libc.a. But i think that cannot be done automatically (the -g flag is almost always passed to the linker, and linking against libc_g.a in that case would be sub-optimal). So that requires some hacking to Makefiles.

[mikrosk]

No, that won't help. That flag would only prevent the application from being blocked. But it is the terminal window that is blocked later when you reenter gdb.

Oh, right. In that case I don't have a better proposal than what you proposed.

the -g flag is almost always passed to the linker, and linking against libc_g.a in that case would be sub-optimal

Yes, there was even explicit commit in our gcc to revert this behaviour as this was exactly the case back then.

[th-otto]

Fun info: im currently trying to debug a crash in the gcc-14 cc1 native compiler. 512MB fast ram was not enough, so i had to increase that to 1GB for aranym. It took more than one hour to load the ~287MB of debug info... And now i have the problem i mentioned above: the crash happens in free(), and i don't get a usable backtrace :(

[mikrosk]

I feel you. (Un)fortunately, the memory hunger isn't limited to Atari: just recently I wanted to use the trick from your patch (make -j$(getconf _NPROCESSORS_ONLN)) so in my case it would build on 16 cores and ... I ran out of 32 GB RAM (!) because I have "only" 8 GB swap enabled.

Insane.

[th-otto]

That is actually dangerous. A few days ago i accidently ran some build process with just -j, thus no limit on jobs. That also got me to the place where the system started to swap (16GB RAM & 32GB swap), until it actually became totally unusable and took about 1min to recognize mouse clicks, so i could switch to a different terminal and kill it. All in all took almost 1hour to get it back to normal operation. Already thought about pressing the reset button...

[mikrosk]

You are more patient than I am, so yes, I did press the reset button. ;-)

[mikrosk]

@th-otto as for your https://github.com/freemint/m68k-atari-mint-binutils-gdb/issues/8#issuecomment-2132700531, I have witnessed it, too. And it's a shame because I wanted to debug exactly such a crash, so gdb should be helping me there and not vice versa.

One solution could be to link against libc_g.a instead of libc.a

Did you verify that this indeed fix the issue?

[th-otto]

Yes, atleast when you compile also your application with -g and -fno-omit-framepointer