add gdb ?

[remisharrock]

is there a way to add GDB https://github.com/openrisc/binutils-gdb ? thanks !

[s-macke]

Proof me wrong, but I think a native gdb is still not supported. I still get the error message "configure: error: "*\ Gdb does not support native target or1k-unknown-linux-musl" when I try to compile this gdb version.

[remisharrock]

hmmmm... the error message is here: https://github.com/openrisc/binutils-gdb/blob/5a0933b80d3d5d6345573a237c9eebb780ccbcbf/gdb/configure.ac#L2199 so "or1k-unknown-linux-musl" is the value of ${host} , shall we dig into their code ?

[remisharrock]

BIG NEWS!!!

We are proud to announce that the OpenRISC port for gdb has been merged upstream. This was done back in December 2017 so its a bit late notice, but here it is.

https://openrisc.io/2018/03/16/gdbupstreamandreleases

Let's JOR1K it! :)

[s-macke]

Ok, will do it

[s-macke]

I have recompiled the toolchain. It looks like I have more to do than just compile gdb. I have to Implement former unused and new CPU instructions.

[remisharrock]

Yes! I was talking to a colleague that told me you would probably need to implement new CPU instructions to support GDB; that's beyond my skills but I can ask him more info if you need!

[s-macke]

No, that's fine. The "safe"-CPU is already working with the new instructions.

[s-macke]

Gdb compiles and runs, but crashes with a segmentation fault as soon as I try to debug something. Also there seems to be another bug somewhere which leads to glitches in the terminal. The error is either in my emulation or gcc or musl. Hard to see. The new Linux kernel also needs some tweaking. Half of my patches for the kernel no longer work.

[remisharrock]

Wow, so much work! That made me smile: debug gdb :) Regarding the glitches, I tried to have a different kind of terminal, what kind of glitches? https://remisharrock.github.io/sysbuild/#/VM

[s-macke]

This is my test environment: https://jor1k.com/jor1k/ Type "help" in the terminal and you see what I mean. The only difference here is, that I use the newest musl-lib and compiled it with the new toolchain using the new instructions. Since musl ist just used to transfer the print commands from the unchanged ncurses libs to the kernel I am a bit puzzled. Now I will try to compile the old musl lib with the new toolchain. I have to fix this problem first before I try to fix the gdb problem.

The big problem here is, that you cannot trust anything here. Everything is just tested by one or two guys. On another architecture usually you can trust gcc,musl and the linux kernel to be well tested and don't contain any errors. Here I cannot trust anything. During the development of jor1k I had to fix problems in almost every module.

[s-macke]

It is not a problem of musl. So it must be either in the new toolchain or in the emulation

[s-macke]

Ok, I was able to compile the new kernel with all patches I need. Also I guess, that the problem with the terminal is a missing feature in my terminal emulation, because the program works fine in xterm. So far, gdb still crashes. I will take a closer look to the or1k part of the gdb to figure out how this is supposed to work. I support the l.trap instruction.

[bsapwindows]

Regarding terminal emulation, have you ever considered switching to xterm.js? it's also friendly with operations like copy and paste within terminal window.

[s-macke]

I have considered it, but I think the main reason was, that such a terminal doesn't support streaming. E. g. it has to handle an incomplete utf-8 byte stream.

[s-macke]

Anyhow, the problem with the terminal is solved. Now, after two weeks, I can finally try to find the problem in gdb.

[s-macke]

I compiled everything without patches and for or1ksim. So nothing jor1k related. The same problems occur when you start gdb. Guess it is easier to ask @stffrdhrn. The problems are segfaults when you run gdb. The easiest way to reproduce the problem is the following code, which can be tested on jor1k.com

~ $ gdb --args
--
SEGFAULT DEBUG: do_page_fault: send sigsegv: address = fffffff5, vector = 300, w
= 0
CPU: 0 PID: 58 Comm: gdb Not tainted 4.16.0+ #1
CPU #: 0
PC: 003fafe8    SR: 0000827e    SP: 00000001
GPR00: 00000000 GPR01: 00000001 GPR02: 00000001 GPR03: 00000001
GPR04: 00000001 GPR05: 3001f173 GPR06: 7f89d6ac GPR07: 00000000
GPR08: 00000000 GPR09: 003fafc8 GPR10: 300bff10 GPR11: 00000005
GPR12: 30000094 GPR13: 3001f173 GPR14: 00000000 GPR15: 30000000
GPR16: 00000000 GPR17: 3001f174 GPR18: 00000000 GPR19: 0000a960
GPR20: 00000000 GPR21: 000007ff GPR22: 00000000 GPR23: 00000000
GPR24: 00000001 GPR25: 00000000 GPR26: 00000000 GPR27: 00000000
GPR28: 00000000 GPR29: 00000000 GPR30: 00000000 GPR31: 00000000
RES: 00000005 oGPR11: ffffffff
Process gdb (pid: 58, stackpage=c1310220)
 
Segmentation fault

[stffrdhrn]

Hello, good to see you are working on this. Sorry for the new instruction requirements. From my brief read through the notes it looks like you are trying to run gdb on Linux binaries. Currently the support is only for native binaries i.e. newlib or the Linux kernel. I would like to get Linux support working but haven't got around to it.

We are currently working on a gcc rewrite https://github.com/stffrdhrn/gcc or1k-port

After this is ready I was planning to look at Linux gdb support. @wbx-github from uclibc-ng has been asking for this for some time.

[s-macke]

Thanks, didn't know that the gdb code is only for bare metal compilation.

Don't worry about the new instructions. The updates were necessary anyhow and I guess in the end they will speed up the emulation a little bit.

[remisharrock]

@stffrdhrn any news on this ? @wbx-github ?

[remisharrock]

looks like it's here ! https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=42e151bf4cc66b8781f2b139c6da320095f9a045

[stffrdhrn]

@remisharrock yes, linux support was added a while back. Sorry, I think this discussion triggered it but I forgot to comment here. I recently used it to debug a new glibc port for OpenRISC and it seems to work fine. Please let me know if it works.