hugsy
display bug , after some commands ,there will be a wrong display
GEF+GDB version
manjaro latest
gdb-multiarch 127 ✘
GNU gdb (GDB) 14.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
GEF for linux ready, type `gef' to start, `gef config' to configure
88 commands loaded and 5 functions added for GDB 14.2 in 0.00ms using Python engine 3.11
Operating System
No response
Describe the issue you encountered
see the picture
Do you read the docs and look at previously closed issues/PRs for similar cases?
No
Architecture impacted
- [ ] X86
- [ ] X64
- [ ] ARM
- [X] ARM64
- [ ] MIPS
- [ ] MIPS64
- [ ] PPC
- [ ] PPC64
- [ ] RISCV
Describe your issue. Without a proper reproduction step-by-step, your issue will be ignored.
start arm64 qemu gdb-multiarch use some command , it wil be ok to see the issue
Minimalist test case
Use this field for a minimal code to compile and spot the issue:
// compile with gcc -fPIE -pic -o my_issue.out my_issue.c
int main(){ return 0; }
You can also provide a Dockerfile if you prefer
Additional context?
for example, i am usingthe following command
print *(struct list_head *)0xffff800009b7ccc8
then the out put will be
_print *(_print *(struct list_head *)0xffff800009b7ccc8
print *( is the wrong output by debuger or cef everytime , the first len("print *(") of letters will be added to the front of the command you typed also the wrongly added letters will be highlighted.
It seems like the problem comes from the boldify line 11237 (and we should have the same issue on the other cases I guess)
Can you try this patch just to check that I'm right, please?
diff --git a/gef.py b/gef.py
index ce95e20..4d49b2d 100644
--- a/gef.py
+++ b/gef.py
@@ -11234,7 +11234,7 @@ class GefRemoteSessionManager(GefSessionManager):
if self == GefRemoteSessionManager.RemoteMode.RR:
return Color.boldify("(rr) ")
if self == GefRemoteSessionManager.RemoteMode.GDBSERVER:
- return Color.boldify("(remote) ")
+ return "(remote) "
raise AttributeError("Unknown value")
def __init__(self, host: str, port: int, pid: int =-1, qemu: Optional[pathlib.Path] = None) -> None:
Hm, our colorify makes sure to use normal at the end, and all our codes start with \033, so I don't understand why this would happen. I also don't see it myself. What terminal emulator are you using?
It is not related to the terminal emulator but to the readline library (which is used by gdb). You can see it by using the up arrow to go to the previous command multiple times when having a remote connection. What happens is that ANSI escape codes are counted by the readline library as taking actual columns in the output, while it doesn't. We need to tell it that those chars are special chars that take no place in the output so that when it computes the length of the prompt, it does not take those chars into account.
That's exactly what the \033[xxxm is supposed to do. I've dealt with this before and never see those codes.
I think you don't understand what the issue is. You can check this thread to understand:
https://stackoverflow.com/questions/50470933/readline-confused-by-ansi-escape-sequences
That's actually what I did, by just copying what is already done on the gef> part of the prompt.
I understand the issue. I have \[ and \] in my bashrc prompt to remediate it. Anyway, we'd probably only need it on the gef> part, as well as (remote) and the other prompts we do.
