GDB TUI windows

[rick.c...@gmail.com]

Is there a way to add windows to GDB's TUI display? Registers?
Watch? Memory address?

And is there a way to assign shortcut keys like F10 to be Step
Over (n), F11 to be Step Into (s), Shift+F11 to be Step Out (is
there a step out ability in gdb??), F5 Continue (c)?

--
Rick C. Hodgin

[Kenny McCormack]

In article <9a696ad0-26f0-47fc...@googlegroups.com>,

Off topic.

--
"The party of Lincoln has become the party of John Wilkes Booth."

- Carlos Alazraqui -

[rick.c...@gmail.com]

I see:

gcc -O0 -g3 progname.c -o progname
gdb --tui progname

tabset 4 -- set 4 character tabs

break main -- Break at main()
break Nnn -- Break on the line number
clear nnn -- Clear a breakpoint

r -- Start the program
c -- Continue after a break
s -- Step into the next line of code
n -- Step over the current line of code
p variable -- Print out the contents of the variable

layout regs -- to see registers
layout split -- to see source + assembly
layout src -- to go back to source only view

As for keystrokes:

https://stackoverflow.com/questions/13090720/key-mapping-in-gdb

1. Start gdb

2. Find the key generated by F7, Press C-v F7
(gdb) ^[[18~

3. nano ~/.inputrc
# Map F7 to next
"\e[18~": "n\n"

4. Restart gdb, and now F7 will be mapped to "next\n"

GDB with the TUI option is not too bad. I've been doing work over ssh
and necessity has forced me to work with GCC + GDB.

--
Rick C. Hodgin

[rick.c...@gmail.com]

On Saturday, July 11, 2020 at 6:32:09 PM UTC-4, Kenny McCormack wrote:
> Off topic.


Shall we conduct our C source code development on white boards for
academic purposes, oh Kenny? Or should we use real editors, comp-
ilers, and debuggers?

--
Rick C. Hodgin

[Bonita Montero]

Using plain gdb is disgusting.
Never use gdb without a GUI-frontend.

[Kenny McCormack]

In article <reemrh$ava$2...@dont-email.me>,

Bonita Montero <Bonita....@gmail.com> wrote:
>Using plain gdb is disgusting.
>Never use gdb without a GUI-frontend.

Off topic. Please take it to a gdb group.

Thank you.

--
"Only a genius could lose a billion dollars running a casino."
"You know what they say: the house always loses."
"When life gives you lemons, don't pay taxes."
"Grab 'em by the p***y!"

[Bonita Montero]

Doesn't matter - you can debug C-pograms with gdb.

[Kenny McCormack]

In article <reeq0n$soj$1...@dont-email.me>,

Bonita Montero <Bonita....@gmail.com> wrote:
>Doesn't matter - you can debug C-pograms with gdb.

Imagine a government-sponsored operation to hunt down and persecute C
programmers...

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Rorschach

[rick.c...@gmail.com]

On Sunday, July 12, 2020 at 6:19:13 AM UTC-4, Kenny McCormack wrote:
> Off topic. Please take it to a gdb group.

Which one, Kenny?

--
Rick C. Hodgin

[David Brown]

Google is a useful tool:

<https://sourceware.org/gdb/onlinedocs/gdb/TUI-Single-Key-Mode.html>

[Öö Tiib]

On Sunday, 12 July 2020 18:54:16 UTC+3, rick....@gmail.com wrote:
> On Sunday, July 12, 2020 at 6:19:13 AM UTC-4, Kenny McCormack wrote:
> > Off topic. Please take it to a gdb group.
>
> Which one, Kenny?

The gnu.gdb and gnu.gdb.bug Usenet groups are inactive.
There is a issue tracker that is active.
<https://sourceware.org/bugzilla/buglist.cgi?component=gdb&product=gdb&resolution=--->
Also the mailing lists are active.
<https://www.gnu.org/software/gdb/mailing-lists/>

[rick.c...@gmail.com]

I think men and women who work in common tools and discuss their common
interests (such as the C computer language) should help one another in
those areas, and even some tangential ones.

People have experience in things. It takes about as much time to write
a reply with the information someone has in the foreground of their
general knowledge, as it does to write a ridiculous reply like "off
topic."

The way to acknowledge periodic off-topic posts is to ignore them. If
the off-topic content continues for some time, then a response is war-
ranted.

In any event, GDB has never been a friend of mine. I've used with some
GUI wrappers (primarily the CodeLite IDE by Eran Ifrah), but it doesn't
compare to Visual Studio's Debugger so I rarely use it except when I
have no choice but to write code that only GCC + GDB supports.

In these past days I've been forced to use SSH to access a Linux machine
and do development. And while I've discovered SSH -X to tunnel X-Windows
it is slow, and it's almost unusable.

In any event, a handful of common commands would get someone started.
I'm sure there are people here who use GCC and GDB daily, and to convey
those commands would be a quick and simple thing. It would someone out
who is seeking knowledge and understanding, and it's relevant to the
needs of someone coding in C because we don't just read the C Standard
and wax philosophical about it. We actually step forward and do, writing
code, debugging code, sharing code, etc.

This wasn't specifically addressed to you, Öö Tiib. It's a general post
for those in clc who are so myopic they can't see human beings on the
other ends of these posts. They just see rules and regulations and hide
behind blindness with regard to the human condition.

I appreciate your help, Öö Tiib. I was able to discover some things about
GDB that have proven helpful. I summarize them here:

gcc -O0 -g3 progname.c -o progname
gdb --tui progname

tabset 4 -- set 4 character tabs

break main -- Break at main()
break Nnn -- Break on the line number
clear nnn -- Clear a breakpoint

r -- Start the program
c -- Continue after a break

k -- Kill the current process

s -- Step into the next line of code
n -- Step over the current line of code
p variable -- Print out the contents of the variable

bt -- Show the stack back trace for the current thread
f Nn -- Such as f 1, show the source code associated with
stack frame number Nn

layout regs -- to see registers
layout split -- to see source + assembly
layout src -- to go back to source only view

Pressing Ctrl+C while the task is running signals SIGINT in Linux, and
stops execution where you are. From there, the commands above can be
used. Typing k to kill, and then r to run will restart the program.

It's worth setting some keys up for STEP, OVER, CONTINUE so that you
aren't constantly typing "s[enter]" or "n[enter]" or "c[enter]", but
just a single F10, F11, and F5, if you're used to Visual Studio.

Still haven't figured out to step out of the current frame. I came
across the command u (Up) but I couldn't figure out how it worked or
if that was it.

Could still use some help.

--
Rick C. Hodgin

PS -- Jesus is more than religion. In fact, He's not even religion.
But what He teaches us about who we are, what sin is, why this
world is the way it is ... it's important. Each of you owe it
to yourself to learn of Jesus because He will teach you about
yourself, and about all the people around you. He will teach
you how to embrace love, and loving people. He will teach you
how to forgive, how to overcome, how to be the men and women He
created us to be before the rigors of this world clobbered each
of us upside the head and set us on other paths.

I cannot stress this enough. Jesus is exactly what all of us
need. He's not religion. He's not punishment. That comes from
other sources. What Jesus brings is life and forgiveness. It is
the sin that He rescues us from that brings everything hurtful and
harmful.

I love each of you. Consider these things, and especially so as
you see the world changing before your very eyes, preparing for
the coming 7-year tribulation where most of mankind will be literally
destroyed. Jesus rescues us from the coming wrath, and gives us what
He intended for us before sin entered in and destroyed everything.

Peace.

[rick.c...@gmail.com]

On Sunday, July 12, 2020 at 5:58:17 AM UTC-4, Bonita Montero wrote:
> Using plain gdb is disgusting.
> Never use gdb without a GUI-frontend.

GDB has a TUI (Text User Interface) which is similar to what we had
back in the DOS days, or what you use in a terminal window. It is
not nearly as nice as a GUI, but it is available when all you have
is a text-based terminal window at your disposal.

The posts I've made in this thread are along those lines, giving
people tools to do work when their options are limited.

--
Rick C. Hodgin

[Lynn McGuire]

Try the debugger in Simply Fortran (which includes GCC) and see if that
helps you. They patterned their debugger after the awesome Watcom
Windows debugger.
http://simplyfortran.com/

Specifically
http://simplyfortran.com/features/debugger

Lynn

[rick.c...@gmail.com]

Thank you, Lynn. Looking forward to it!

--
Rick C. Hodgin

[Manfred]

Bumping up this info (for visibility)

[Manfred]

On 7/13/2020 12:08 AM, rick.c...@gmail.com wrote:

>
> In any event, GDB has never been a friend of mine. I've used with some
> GUI wrappers (primarily the CodeLite IDE by Eran Ifrah), but it doesn't
> compare to Visual Studio's Debugger so I rarely use it except when I
> have no choice but to write code that only GCC + GDB supports.

gdb is rather unfriendly in the beginning, but it is a really powerful
debugger, well worth learning IMO. gdbserver too.

>
> In these past days I've been forced to use SSH to access a Linux machine
> and do development. And while I've discovered SSH -X to tunnel X-Windows
> it is slow, and it's almost unusable.

I would suggest checking network and/or security settings, or the
quality of the X-windows server. I have even been using Eclipse through
a ssh X-Windows tunnel, and it worked like a charm (granted, it was
within a LAN, but I'm not sure how critical is raw network speed for X)

>
> In any event, a handful of common commands would get someone started.
> I'm sure there are people here who use GCC and GDB daily, and to convey
> those commands would be a quick and simple thing. It would someone out
> who is seeking knowledge and understanding, and it's relevant to the
> needs of someone coding in C because we don't just read the C Standard
> and wax philosophical about it. We actually step forward and do, writing
> code, debugging code, sharing code, etc.

See some bumped-up info elsethread.

[rick.c...@gmail.com]

On Monday, July 13, 2020 at 11:04:34 AM UTC-4, Manfred wrote:
> gdb is rather unfriendly in the beginning, but it is a really powerful
> debugger, well worth learning IMO. gdbserver too.

It seems adequate. It's just so verbose. Manual commands. Clunky.

> > In these past days I've been forced to use SSH to access a Linux machine
> > and do development. And while I've discovered SSH -X to tunnel X-Windows
> > it is slow, and it's almost unusable.
>
> I would suggest checking network and/or security settings, or the
> quality of the X-windows server. I have even been using Eclipse through
> a ssh X-Windows tunnel, and it worked like a charm (granted, it was
> within a LAN, but I'm not sure how critical is raw network speed for X)

Try it. It was much worse than apps like TeamViewer.

> > In any event, a handful of common commands would get someone started.
> > I'm sure there are people here who use GCC and GDB daily, and to convey
> > those commands would be a quick and simple thing. It would someone out
> > who is seeking knowledge and understanding, and it's relevant to the
> > needs of someone coding in C because we don't just read the C Standard
> > and wax philosophical about it. We actually step forward and do, writing
> > code, debugging code, sharing code, etc.
>
> See some bumped-up info elsethread.

I don't read anything DB posts. He was consistently hurtful and dis-
couraging to me over the course of many years, and I have zero interest
in anything he has to say ever again.

"Fredo, you're nothing to me now. You're not a brother, you're not a
friend. I don't want to know you or what you do. I don't want to see
you at the hotels, I don't want you near my house. When you see our
mother, I want to know a day in advance, so I won't be there. You
understand?"

And then some.

--
Rick C. Hodgin

[David Brown]

On 13/07/2020 17:04, Manfred wrote:
> On 7/13/2020 12:08 AM, rick.c...@gmail.com wrote:
>
>>
>> In any event, GDB has never been a friend of mine.  I've used with some
>> GUI wrappers (primarily the CodeLite IDE by Eran Ifrah), but it doesn't
>> compare to Visual Studio's Debugger so I rarely use it except when I
>> have no choice but to write code that only GCC + GDB supports.
>
> gdb is rather unfriendly in the beginning, but it is a really powerful
> debugger, well worth learning IMO. gdbserver too.
>
>>
>> In these past days I've been forced to use SSH to access a Linux machine
>> and do development.  And while I've discovered SSH -X to tunnel X-Windows
>> it is slow, and it's almost unusable.
>
> I would suggest checking network and/or security settings, or the
> quality of the X-windows server. I have even been using Eclipse through
> a ssh X-Windows tunnel, and it worked like a charm (granted, it was
> within a LAN, but I'm not sure how critical is raw network speed for X)
>

X can be very sensitive to latency, more than bandwidth. But programs
vary a lot as to how friendly they are to X over a network - lots of
fancy graphics effects look great locally, but are poor remotely.

For gdb with a front-end (eclipse, ddd, CodeLite, etc.), it makes more
sense to run the gdb remotely and have a local running front-end that
connects to it, rather than running the gui part of the debugger remotely.

(This is all off-topic here, of course - details are best found with
google. I'm just giving a few pointers.)

[Kenny McCormack]

In article <reht5q$1dck$1...@gioia.aioe.org>, Manfred <non...@add.invalid> wrote:
...

>> In these past days I've been forced to use SSH to access a Linux machine
>> and do development. And while I've discovered SSH -X to tunnel X-Windows
>> it is slow, and it's almost unusable.

>I have even been using Eclipse through
>a ssh X-Windows tunnel, and it worked like a charm (granted, it was
>within a LAN, but I'm not sure how critical is raw network speed for X)

I can attest that X over ssh is slower than VNC - for at least some
applications. I think it is (or should be) common knowledge that it (X
over ssh) isn't really a good idea for WAN (i.e., non-LAN) applications
unless the app is trivial (i.e., a simple xterm or an editor should be OK).

--
Modern Conservative: Someone who can take time out from demanding more
flag burning laws, more abortion laws, more drug laws, more obscenity
laws, and more police authority to make warrantless arrests to remind
us that we need to "get the government off our backs".

[Manfred]

On 7/13/2020 5:33 PM, rick.c...@gmail.com wrote:
> On Monday, July 13, 2020 at 11:04:34 AM UTC-4, Manfred wrote:
>> gdb is rather unfriendly in the beginning, but it is a really powerful
>> debugger, well worth learning IMO. gdbserver too.
>
> It seems adequate. It's just so verbose. Manual commands. Clunky.

Manual commands mean that you have a *lot* more commands available than
can fit in a GUI.

>
>>> In these past days I've been forced to use SSH to access a Linux machine
>>> and do development. And while I've discovered SSH -X to tunnel X-Windows
>>> it is slow, and it's almost unusable.
>>
>> I would suggest checking network and/or security settings, or the
>> quality of the X-windows server. I have even been using Eclipse through
>> a ssh X-Windows tunnel, and it worked like a charm (granted, it was
>> within a LAN, but I'm not sure how critical is raw network speed for X)
>
> Try it. It was much worse than apps like TeamViewer.

As I said, I used it and I use it. The ssh tunnel works fine. I even
remember a case where the tunneled eclipse was /faster/ than used
locally - the remote machine that eclipse was running on was an old
32-bit system with poor display hardware, that would bend under the
weight of the full X-windows desktop.

Obviously this has nothing to do with anything like Remote Desktop or
TeamViewer - remote X-Windows apps are a totally different (and better)
thing.

[Manfred]

On 7/13/2020 5:36 PM, David Brown wrote:
> On 13/07/2020 17:04, Manfred wrote:
>> On 7/13/2020 12:08 AM, rick.c...@gmail.com wrote:
>>
>>>
>>> In any event, GDB has never been a friend of mine.  I've used with some
>>> GUI wrappers (primarily the CodeLite IDE by Eran Ifrah), but it doesn't
>>> compare to Visual Studio's Debugger so I rarely use it except when I
>>> have no choice but to write code that only GCC + GDB supports.
>>
>> gdb is rather unfriendly in the beginning, but it is a really powerful
>> debugger, well worth learning IMO. gdbserver too.
>>
>>>
>>> In these past days I've been forced to use SSH to access a Linux machine
>>> and do development.  And while I've discovered SSH -X to tunnel X-Windows
>>> it is slow, and it's almost unusable.
>>
>> I would suggest checking network and/or security settings, or the
>> quality of the X-windows server. I have even been using Eclipse through
>> a ssh X-Windows tunnel, and it worked like a charm (granted, it was
>> within a LAN, but I'm not sure how critical is raw network speed for X)
>>
>
> X can be very sensitive to latency, more than bandwidth. But programs
> vary a lot as to how friendly they are to X over a network - lots of
> fancy graphics effects look great locally, but are poor remotely.
>
> For gdb with a front-end (eclipse, ddd, CodeLite, etc.), it makes more
> sense to run the gdb remotely and have a local running front-end that
> connects to it, rather than running the gui part of the debugger remotely.

If you have to debug remotely gdbserver is pretty useful.

>
> (This is all off-topic here, of course - details are best found with
> google. I'm just giving a few pointers.)

Techinally it is off-topic, yes. But Rick is right that using gdb is not
that much of an alien to C development.
One example is server code, an area where C dominates. If you have to
debug server software then probably ssh, gdb and gdbserver are some
must-have tools in your box.
(For the record, I do not praise an intense use of debuggers when
writing code)

[Kenny McCormack]

In article <rei38n$f91$1...@gioia.aioe.org>, Manfred <non...@add.invalid> wrote:
...

>Techinally it is off-topic, yes. But Rick is right that using gdb is
>not that much of an alien to C development. One example is server code,
>an area where C dominates. If you have to debug server software then
>probably ssh, gdb and gdbserver are some must-have tools in your box.

Kiki will tell you otherwise.

--
Faith doesn't give you the answers; it just stops you from asking the questions.

[David Brown]

Yes.

Most of my debugging is with embedded systems, so typically gdb
communicates with software (like OpenOCD) that handles a JTAG interface,
and that's another communication channel that can be over a network.
There's lots of possibilities.

>
>>
>> (This is all off-topic here, of course - details are best found with
>> google.  I'm just giving a few pointers.)
>
> Techinally it is off-topic, yes. But Rick is right that using gdb is not
> that much of an alien to C development.

Agreed. That's why I answered his posts.

> One example is server code, an area where C dominates. If you have to
> debug server software then probably ssh, gdb and gdbserver are some
> must-have tools in your box.
> (For the record, I do not praise an intense use of debuggers when
> writing code)

Agreed.

>
>>
>>>>
>>>> In any event, a handful of common commands would get someone started.
>>>> I'm sure there are people here who use GCC and GDB daily, and to convey
>>>> those commands would be a quick and simple thing.  It would someone out
>>>> who is seeking knowledge and understanding, and it's relevant to the
>>>> needs of someone coding in C because we don't just read the C Standard
>>>> and wax philosophical about it.  We actually step forward and do,
>>>> writing
>>>> code, debugging code, sharing code, etc.
>>>
>>> See some bumped-up info elsethread.
>>
>

I don't know if Rick will read it, since I wrote the post. But that's
his problem, not yours or mine.

[Scott Lurndal]

Manfred <non...@add.invalid> writes:
>On 7/13/2020 12:08 AM, rick.c...@gmail.com wrote:
>
>>
>> In any event, GDB has never been a friend of mine. I've used with some
>> GUI wrappers (primarily the CodeLite IDE by Eran Ifrah), but it doesn't
>> compare to Visual Studio's Debugger so I rarely use it except when I
>> have no choice but to write code that only GCC + GDB supports.
>
>gdb is rather unfriendly in the beginning, but it is a really powerful
>debugger, well worth learning IMO. gdbserver too.
>
>>
>> In these past days I've been forced to use SSH to access a Linux machine
>> and do development. And while I've discovered SSH -X to tunnel X-Windows
>> it is slow, and it's almost unusable.
>
>I would suggest checking network and/or security settings, or the
>quality of the X-windows server. I have even been using Eclipse through
>a ssh X-Windows tunnel, and it worked like a charm (granted, it was
>within a LAN, but I'm not sure how critical is raw network speed for X)

It's quite critical. What works on a LAN won't work as well over the WAN.

Athena Widgets applications are the exception - primarily because
they don't use fancy graphics or renders, just simple boxes and
fonts.

I'm use XRN over a <VPN> -> <WAN> -> <LAN VNCSERVER> -> <WAN> -> <VPN> -> <VNCCLIENT>
and it's perfectly usable ( albeit keystroke latency is sometimes noticable).

GTK and QT apps, particularly graphic happy apps, aren't usable over most WANs
(unless you have a 10Gbit pipe).

[Lynn McGuire]

On 7/11/2020 5:31 PM, Kenny McCormack wrote:
> In article <9a696ad0-26f0-47fc...@googlegroups.com>,
> <rick.c...@gmail.com> wrote:
>> Is there a way to add windows to GDB's TUI display? Registers?
>> Watch? Memory address?
>>
>> And is there a way to assign shortcut keys like F10 to be Step
>> Over (n), F11 to be Step Into (s), Shift+F11 to be Step Out (is
>> there a step out ability in gdb??), F5 Continue (c)?
>
> Off topic.

No, it is not.

Lynn

[Kenny McCormack]

In article <reije2$am2$1...@dont-email.me>,

Absolutely, yes, it is.

Kiki will back me up on this.

--
Joni Ernst (2014): Obama should be impeached because 2 people have died of Ebola.
Joni Ernst (2020): Trump is doing great things, because only 65,000 times as many people have died of COVID-19.

Josef Stalin (1947): When one person dies, it is a tragedy; when a million die, it is merely statistics.

[jacobnavia]

That thing is a joke. Bad quality in user interfaces is a signature of
GNU but that is really one of the BEST examples!

1) No mouse of course, even if text based mouse interfaces exist under
linux (gpm)

2) If you invoke a shell the terminal is left in a "noecho" state (you
do not see what you type) and no CR of course. To avoid that type "stty
sane" when you arrive at the shell

3) when you return from the shell the screen is garbled, no automatic
refresh, unusable. Just exit and estart gdb.

4) It has only one window for the source, either the C source or the
assembler display, and one overlays the other. Once you see the
registers there is no obvious command to see the C code again... unless
you read again the doc and YES! "layout split" gets you the C display
back but the register window is gone.

Note that I have a 32 inch monitor capable of displaying several hundred
characters but enlarging the window just displays more black background.

5) No automatic display of the variables used by the program. You MUST
type print foo print foo2 AD NAUSEAUM.

6) If you resize the window where gdb is running the command display is
garbled and you no longer see what commands you type. To avoid this just
get out of gdb loosing everything and restart it again.

7) The arrows are used to scroll in the C source window. It is
impossible now to recall a previous command with the arrows, so you have
to type print foo OVER AND OVER AGAIN! Yes, an empty line reruns the
last command. But only the last, not the print statement just 2 lines ago.


8) The debugger doesn't understand that memset is a c library function,
and when running in step mode you get into memset, the debugger displays
"no source" and you have to type as many times return as there are asm
statements that are executed... and if you get in a loop of 10 000 runs
you are stuck forever, unless you figure out what command takes you out
of that. And no, "until" doesn't work even if the doc says that it
should bring you to the next source line...
If in trouble, just get out of gdb and start over.

Another work around is to type "where" and set a breakpoint in the next
line of the calling function and then unset it when you reach it.
"where" displays the stack. Then "up 1" takes you to the calling
function. Then "b 24" sets a breakpoint at the next line (if you are in
line 23) and then "c" tells gdb to continue and it stops after the call
to memset.

Of course GNU fans will love this thing and any suggestion to the
developers will be met with the usual: "You have the source, write your
own!"

I will do that, eventually, as I did under windows...

jacob

[fir]

W dniu wtorek, 14 lipca 2020 02:06:06 UTC+2 użytkownik Kenny McCormack napisał:
> In article <reije2$am2$1...@dont-email.me>,
> Lynn McGuire <lynnmc...@gmail.com> wrote:
> >On 7/11/2020 5:31 PM, Kenny McCormack wrote:
> >> In article <9a696ad0-26f0-47fc...@googlegroups.com>,
> >> <rick.c...@gmail.com> wrote:
> >>> Is there a way to add windows to GDB's TUI display? Registers?
> >>> Watch? Memory address?
> >>>
> >>> And is there a way to assign shortcut keys like F10 to be Step
> >>> Over (n), F11 to be Step Into (s), Shift+F11 to be Step Out (is
> >>> there a step out ability in gdb??), F5 Continue (c)?
> >>
> >> Off topic.
> >
> >No, it is not.
>
> Absolutely, yes, it is.
>
> Kiki will back me up on this.
>

imo it isnt but not this is a problem

problem is dik iw well knowm imbecile and massive spammer.. dont people remember how he massively imbecilized this group for years and hov much better
this group is without this imbescile...
thats why people who politely answer to that imbecile play as a kinda half-trolls here... do you realy want to turn off this disgusting pis swamp again?
if you are and if you dont care youre kinda half-troll which is just bad

i can say i developed my ovn opinion of some kinda low intelligence of some users here not becouse they technical answers (which often are ok ) but just becouse that half-trolling practices which seem they cant resist :c its sad

[rick.c...@gmail.com]

On Tuesday, July 14, 2020 at 5:20:54 AM UTC-4, jacobnavia wrote:
> 3) when you return from the shell the screen is garbled, no automatic
> refresh, unusable. Just exit and estart gdb.

Ctrl+L will redraw the screen.

> 4) It has only one window for the source, either the C source or the
> assembler display, and one overlays the other. Once you see the
> registers there is no obvious command to see the C code again... unless
> you read again the doc and YES! "layout split" gets you the C display
> back but the register window is gone.
>
> Note that I have a 32 inch monitor capable of displaying several hundred
> characters but enlarging the window just displays more black background.

Why don't you write a CodeView-like wrapper for GDB for terminal windows?
You'd be helping probably 100s of thousands of users.

> 5) No automatic display of the variables used by the program. You MUST
> type print foo print foo2 AD NAUSEAUM.
>
> 6) If you resize the window where gdb is running the command display is
> garbled and you no longer see what commands you type. To avoid this just
> get out of gdb loosing everything and restart it again.
>
> 7) The arrows are used to scroll in the C source window. It is
> impossible now to recall a previous command with the arrows, so you have
> to type print foo OVER AND OVER AGAIN! Yes, an empty line reruns the
> last command. But only the last, not the print statement just 2 lines ago.
>
>
> 8) The debugger doesn't understand that memset is a c library function,
> and when running in step mode you get into memset, the debugger displays
> "no source" and you have to type as many times return as there are asm
> statements that are executed... and if you get in a loop of 10 000 runs
> you are stuck forever, unless you figure out what command takes you out
> of that. And no, "until" doesn't work even if the doc says that it
> should bring you to the next source line...
> If in trouble, just get out of gdb and start over.

Type "b Nnn" and then "c" and it will break at the line number or
address. You can skip loops that way.

> Another work around is to type "where" and set a breakpoint in the next
> line of the calling function and then unset it when you reach it.
> "where" displays the stack. Then "up 1" takes you to the calling
> function.

Thank you! I couldn't figure out the "up" syntax. "bt" back trace also
shows you the stack frame.

I don't know how to list threads or stay focused on a single thread.

> Then "b 24" sets a breakpoint at the next line (if you are in
> line 23) and then "c" tells gdb to continue and it stops after the call
> to memset.
>
> Of course GNU fans will love this thing and any suggestion to the
> developers will be met with the usual: "You have the source, write your
> own!"
>
> I will do that, eventually, as I did under windows...

I have written a few debuggers, two for my own OS (real mode plus
kernel), and a few for Windows.

Writing a CodeView-like wrapper for GDB might be a nice project. If you
want to collaborate, let me know.

--
Rick C. Hodgin

[rick.c...@gmail.com]

On Tuesday, July 14, 2020 at 5:25:07 AM UTC-4, fir wrote:
> dik

My name is Rick, fir. If you won't have respect for me, then at least
have respect for you.

I think you miss the point of my messages, and conclude incorrectly in
summary something of your own assumption, rather than of my actual
writings. The things I post teach you how to find love for people,
how to cast off hate, how to find helping, how to find uplifting, to
be a positive force in someone's life, in everyone's life. The issue
you have with me is not an issue with me. I am not rude, mean, or any
such thing. I am helpful, hopeful, desirous in all of us having a
future. What you reject is that which I embrace: Jesus. He, and what
He represents, is what you reject. You are thinking incorrectly about
Him, using your own generated conclusions rather than investigating for
discovery of the real truth of His teachings.

They say, "the devil is in the details." That's incorrect. The truth
is, "The devil is in a glossing over of the details, and in a summary
assessment without investigation."

Do you respect yourself? If so, you owe it to yourself to investigate
the truth.

Regardless, someday you will know the truth. All people will know the
truth, even if they reject Him today.

My goals are to save people from that day. It's exceedingly important.

--
Rick C. Hodgin

[David Brown]

On 14/07/2020 11:20, jacobnavia wrote:
> Le 12/07/2020 à 18:50, David Brown a écrit :
>> On 12/07/2020 00:17, rick.c...@gmail.com wrote:
>>> Is there a way to add windows to GDB's TUI display?  Registers?
>>> Watch?  Memory address?
>>>
>>> And is there a way to assign shortcut keys like F10 to be Step
>>> Over (n), F11 to be Step Into (s), Shift+F11 to be Step Out (is
>>> there a step out ability in gdb??), F5 Continue (c)?
>>>
>>
>> Google is a useful tool:
>>
>> <https://sourceware.org/gdb/onlinedocs/gdb/TUI-Single-Key-Mode.html>
>>
>
> That thing is a joke. Bad quality in user interfaces is a signature of
> GNU but that is really one of the BEST examples!
>

I didn't say TUI is a particularly good interface - I have never used it
myself, so I can't really say. The OP wanted to know the keys for it,
and how to make them shorter, so I gave him a link.

I find gdb bare command line interface useful at times. I have used it
over ssh, used it to automate tasks via a debugger (such as programming
and testing embedded systems), and occasionally used it for small tasks
for convenience. Mostly I use a front-end (such as Eclipse, but I've
used others) for my gdb work.


If you don't like TUI for gdb, don't use it. It's rarely something
forced on people.

>
>
> 8) The debugger doesn't understand that memset is a c library function,
> and when running in step mode you get into memset, the debugger displays
> "no source"

I suspect that is nothing to do with the debugger. Either you are not
using a debug version of the library (and therefore have no symbols or
source), or the compiler has inlined the memset (and therefore there is
no source).

>
> Of course GNU fans will love this thing and any suggestion to the
> developers will be met with the usual: "You have the source, write your
> own!"
>

I find gdb to be a useful debugger. I don't think it is perfect, and
there is plenty of room for improvement both on gdb and on front-ends
that I use. It's the only option for much of the stuff I do, and better
than alternatives that I have tried for some other things (where
"better" is of course highly subjective and influenced by familiarity).

Other people have different needs and wants. If you don't like it, and
work on platforms where there are alternatives, then try an alternative.
Moaning and listing a range of complaints about a particular debugger
to a C language group seems a spectacularly pointless exercise.

[Malcolm McLean]

On Tuesday, 14 July 2020 10:20:54 UTC+1, jacobnavia wrote:
>
> That thing is a joke. Bad quality in user interfaces is a signature of
> GNU but that is really one of the BEST examples!
>

The experience of applications development is that the complexity and polish
of the user interface is the main influence on development time.

Good UI s difficult to do. And a lot of the skills you need are not
programming skills as such, but artistic skills and psychology.

[Manfred]

On 7/14/2020 1:56 PM, Malcolm McLean wrote:
> Good UI s difficult to do. And a lot of the skills you need are not
> programming skills as such, but artistic skills and psychology.

Good point. Long time ago I met one person who was designing (software)
control UIs for machine systems produced by a huge company.
Guess what, no software background at all, that person was a psychologist!

[jacobnavia]

Le 14/07/2020 à 13:21, David Brown a écrit :
> On 14/07/2020 11:20, jacobnavia wrote:
>> Le 12/07/2020 à 18:50, David Brown a écrit :
>>> On 12/07/2020 00:17, rick.c...@gmail.com wrote:
>>>> Is there a way to add windows to GDB's TUI display?  Registers?
>>>> Watch?  Memory address?
>>>>
>>>> And is there a way to assign shortcut keys like F10 to be Step
>>>> Over (n), F11 to be Step Into (s), Shift+F11 to be Step Out (is
>>>> there a step out ability in gdb??), F5 Continue (c)?
>>>>
>>>
>>> Google is a useful tool:
>>>
>>> <https://sourceware.org/gdb/onlinedocs/gdb/TUI-Single-Key-Mode.html>
>>>
>>
>> That thing is a joke. Bad quality in user interfaces is a signature of
>> GNU but that is really one of the BEST examples!
>>
>
> I didn't say TUI is a particularly good interface - I have never used it
> myself, so I can't really say. The OP wanted to know the keys for it,
> and how to make them shorter, so I gave him a link.
>

I had never used it before either. I try to avoid GNU user interfaces as
much as I can, so I gave it a try. It took me 10 minutes to find all the
bugs I wrote in my message and that you do not even mention...

> I find gdb bare command line interface useful at times. I have used it
> over ssh, used it to automate tasks via a debugger (such as programming
> and testing embedded systems), and occasionally used it for small tasks
> for convenience. Mostly I use a front-end (such as Eclipse, but I've
> used others) for my gdb work.
>

Eclipse is a java stuff that will eat all your machine just to do the
IDE. But it is probably better than TUI...

>
> If you don't like TUI for gdb, don't use it. It's rarely something
> forced on people.
>

Yeah, "if you don't like it"... That sentence has two sides: 1: It is
just a matter of "dislike" of my part, not of obvious bugs. 2: Since
like or dislikes are subjective, the obvious bugs disappear. It is just
that I do not like it.

>>
>>
>> 8) The debugger doesn't understand that memset is a c library function,
>> and when running in step mode you get into memset, the debugger displays
>> "no source"
>
> I suspect that is nothing to do with the debugger. Either you are not
> using a debug version of the library (and therefore have no symbols or
> source), or the compiler has inlined the memset (and therefore there is
> no source).

The debugger should be able to load the debug version of libc, even
Microsoft's MSVC does that... And if it hasn't the source there is NO
POINT in showing a blank screen don't you think so? Just going over the
call as most debuggers do would be enough!

>
>>
>> Of course GNU fans will love this thing and any suggestion to the
>> developers will be met with the usual: "You have the source, write your
>> own!"
>>
>
> I find gdb to be a useful debugger. I don't think it is perfect, and
> there is plenty of room for improvement both on gdb and on front-ends
> that I use. It's the only option for much of the stuff I do, and better
> than alternatives that I have tried for some other things (where
> "better" is of course highly subjective and influenced by familiarity).
>
> Other people have different needs and wants. If you don't like it, and
> work on platforms where there are alternatives, then try an alternative.

As I said before, I "do not like it". You like bugs David? Here it's not
a matter of "liking it" or not, it is being forced to quit because you
do not see what you type, or being confronted to a blank "no source"
screen that tells you nothing. It doesn't even come to the idea of
displaying the assembler as other debuggers do when there is no source!

> Moaning and listing a range of complaints about a particular debugger
> to a C language group seems a spectacularly pointless exercise.
>

"Moaning". A bug description is "moaning". Typical GNU reaction. Bug
descriptions are ust "moaning" complaining" and the sempiternal "if you
do not like the bugs go somewhere else"

Well, let it be, as Lennon said.

[jacobnavia]

Wait a second, figuring out that when you invoke a shell from the
debugger, the user interface should reset the terminal to sane, and then
when you come back it should set the terminal as it was before is just
plain software TESTING. It doesn't need any psychological stuff!

The other bugs are also just common sense. All debuggers display
assembler or do not enter in a function where the source is not
available, only gdb will display a black screen with "no source"...

And screen resizing is a normal thing in todays "xterms" that aren't
text based at all. The mouse interface is available through known
interfaces, if you do not use that it is your fault, not the user's and
you do not need any psychology to figure out that a mouse is useful,
coupled with a menu. It allows giving focus to different windows...

This is so old (at least 20 years of GUIs) so I thought that would be
standard now.

jacob

[David Brown]

On 14/07/2020 16:57, jacobnavia wrote:
> Le 14/07/2020 à 13:21, David Brown a écrit :
>> On 14/07/2020 11:20, jacobnavia wrote:
>>> Le 12/07/2020 à 18:50, David Brown a écrit :
>>>> On 12/07/2020 00:17, rick.c...@gmail.com wrote:
>>>>> Is there a way to add windows to GDB's TUI display?  Registers?
>>>>> Watch?  Memory address?
>>>>>
>>>>> And is there a way to assign shortcut keys like F10 to be Step
>>>>> Over (n), F11 to be Step Into (s), Shift+F11 to be Step Out (is
>>>>> there a step out ability in gdb??), F5 Continue (c)?
>>>>>
>>>>
>>>> Google is a useful tool:
>>>>
>>>> <https://sourceware.org/gdb/onlinedocs/gdb/TUI-Single-Key-Mode.html>
>>>>
>>>
>>> That thing is a joke. Bad quality in user interfaces is a signature of
>>> GNU but that is really one of the BEST examples!
>>>
>>
>> I didn't say TUI is a particularly good interface - I have never used it
>> myself, so I can't really say.  The OP wanted to know the keys for it,
>> and how to make them shorter, so I gave him a link.
>>
>
> I had never used it before either. I try to avoid GNU user interfaces as
> much as I can, so I gave it a try. It took me 10 minutes to find all the
> bugs I wrote in my message and that you do not even mention...

I don't think gui's are considered the traditional strong point of the
GNU project. And your list is a matter of opinions, and completely
irrelevant here (no matter how valid some of them might be - and
equally, no matter how wrong some might be).

>
>> I find gdb bare command line interface useful at times.  I have used it
>> over ssh, used it to automate tasks via a debugger (such as programming
>> and testing embedded systems), and occasionally used it for small tasks
>> for convenience.  Mostly I use a front-end (such as Eclipse, but I've
>> used others) for my gdb work.
>>
>
> Eclipse is a java stuff that will eat all your machine just to do the
> IDE. But it is probably better than TUI...
>

If you don't like it, don't use it. There are a hundred and one other
IDE's available, many of which have front-ends for gdb, others which
have different debuggers. And many people don't like to use an IDE at
all. Use what you fancy.

>>
>> If you don't like TUI for gdb, don't use it.  It's rarely something
>> forced on people.
>>
>
> Yeah, "if you don't like it"... That sentence has two sides: 1: It is
> just a matter of "dislike" of my part, not of obvious bugs.

Correct. (Some of your list might be bugs, but others are opinions.)

> 2: Since
> like or dislikes are subjective, the obvious bugs disappear. It is just
> that I do not like it.

If you find bugs - real bugs, not just opinions - you can report them
somewhere /useful/. If you think there are missing features or changes
that you would recommend, that are realistic for the project, then you
can report these too - somewhere /appropriate/.

I don't use TUI with gdb. I doubt if many people here do. From the
little I know of it, it is not really an active project at all, and few
people anywhere make much use of it.

>
>>>
>>>
>>> 8) The debugger doesn't understand that memset is a c library function,
>>> and when running in step mode you get into memset, the debugger displays
>>> "no source"
>>
>> I suspect that is nothing to do with the debugger.  Either you are not
>> using a debug version of the library (and therefore have no symbols or
>> source), or the compiler has inlined the memset (and therefore there is
>> no source).
>
> The debugger should be able to load the debug version of libc, even
> Microsoft's MSVC does that... And if it hasn't the source there is NO
> POINT in showing a blank screen don't you think so? Just going over the
> call as most debuggers do would be enough!
>

Since I don't use native gdb to any significant degree (on my targets,
the C library is static), I can't help you. But I would be rather
surprised to hear that you are the first person to use gdb with a
program that uses memset. So rather than a bug in gdb, my bet would be
on a misunderstanding or a missing detail of compiling, linking or
debugging. After all, you've only been trying for 10 minutes, and I
think it's fair to say that gdb (and gcc) are not always obvious in
their usage.

>
>>
>>>
>>> Of course GNU fans will love this thing and any suggestion to the
>>> developers will be met with the usual: "You have the source, write your
>>> own!"
>>>
>>
>> I find gdb to be a useful debugger.  I don't think it is perfect, and
>> there is plenty of room for improvement both on gdb and on front-ends
>> that I use.  It's the only option for much of the stuff I do, and better
>> than alternatives that I have tried for some other things (where
>> "better" is of course highly subjective and influenced by familiarity).
>>
>> Other people have different needs and wants.  If you don't like it, and
>> work on platforms where there are alternatives, then try an alternative.
>
> As I said before, I "do not like it". You like bugs David? Here it's not
> a matter of "liking it" or not, it is being forced to quit because you
> do not see what you type, or being confronted to a blank "no source"
> screen that tells you nothing. It doesn't even come to the idea of
> displaying the assembler as other debuggers do when there is no source!
>
>
>>   Moaning and listing a range of complaints about a particular debugger
>> to a C language group seems a spectacularly pointless exercise.
>>
>
> "Moaning". A bug description is "moaning". Typical GNU reaction. Bug
> descriptions are ust "moaning" complaining" and the sempiternal  "if you
> do not like the bugs go somewhere else"

I'm sorry, you seem to be confusing this C language newsgroup with the
mailing list for gdb development. And you seem to be confusing me with
a GNU developer who works on gdb TUI.

[Scott Lurndal]

David Brown <david...@hesbynett.no> writes:
>On 14/07/2020 16:57, jacobnavia wrote:

>>>> 8) The debugger doesn't understand that memset is a c library function,
>>>> and when running in step mode you get into memset, the debugger displays
>>>> "no source"
>>>
>>> I suspect that is nothing to do with the debugger.  Either you are not
>>> using a debug version of the library (and therefore have no symbols or
>>> source), or the compiler has inlined the memset (and therefore there is
>>> no source).
>>
>> The debugger should be able to load the debug version of libc, even
>> Microsoft's MSVC does that... And if it hasn't the source there is NO
>> POINT in showing a blank screen don't you think so? Just going over the
>> call as most debuggers do would be enough!
>>
>
>Since I don't use native gdb to any significant degree (on my targets,
>the C library is static), I can't help you. But I would be rather
>surprised to hear that you are the first person to use gdb with a
>program that uses memset. So rather than a bug in gdb, my bet would be
>on a misunderstanding or a missing detail of compiling, linking or
>debugging. After all, you've only been trying for 10 minutes, and I
>think it's fair to say that gdb (and gcc) are not always obvious in
>their usage.

I use gdb every day (command line, not TUI, not DDD). It handles
libc functions just fine, if:

1) it has access to the debug symbols (generally a separate RPM
on Redhat and Redhat derived distributions)
and
2) You've loaded the corresponding glibc sources somewhere so gdb can find them
(again, an additional RPM (package) on redhat and derived distros).

The typical application that I debug uses a dozen system shared objects
(from glibc and libstdc++ to libgmp) and several dozen run-time loaded
shared objects, and gdb has no problem finding either source or symbol
tables for any of them.

We generally distribute a stripped ELF and stripped shared objects, but
we preserve the symbols in a separate package for internal debugging
and analyzing core files from users; pointing gdb to those symbol files
is trival (and even automatic if you mimic the build environment, or have
the original build environment handy).

[Elijah Stone]

On Tue, 14 Jul 2020, fir wrote:

> problem is dik[sic] iw[sic] well knowm[sic] imbecile and massive
> spammer.. dont[sic] people remember how he massively imbecilized[sic]
> this group for years and hov[sic] much better this group is without this
> imbescile[sic]...

If he is asking on-topic questions now, then so much the better; that
should be encouraged.

--
time flies like an arrow;
fruit flies like a banana

[Elijah Stone]

On Sat, 11 Jul 2020, rick.c...@gmail.com wrote:

> Is there a way to add windows to GDB's TUI display?

'layout asm' -> 'C-x 2'


> Registers?
'layout next' a bunch until you're satisfied with the displayed windows.


> Watch? Memory address?
Simple as 'watch <variable-name>' or 'watch (type*)memory-address'. ('wa'
for short.)

> is there a step out ability in gdb??

'finish'

[rick.c...@gmail.com]

On Tuesday, July 14, 2020 at 9:18:48 PM UTC-4, Elijah Stone wrote:
> On Sat, 11 Jul 2020, rick.c...@gmail.com wrote:
> > Is there a way to add windows to GDB's TUI display?
> 'layout asm' -> 'C-x 2'
>
>
> > Registers?
> 'layout next' a bunch until you're satisfied with the displayed windows.
>
>
> > Watch? Memory address?
> Simple as 'watch <variable-name>' or 'watch (type*)memory-address'. ('wa'
> for short.)
>
>
> > is there a step out ability in gdb??
> 'finish'

Thank you!!

--
Rick C. Hodgin

[John A. Zoidberg]

Bonita Montero <Bonita....@gmail.com> wrote:

> Using plain gdb is disgusting.

The fact that you don't know how to do it doesn't make it disgusting.

--
Motor gently through the greasemud, for there lurks the skid demon.

[jacobnavia]

Le 17/07/2020 à 13:30, John A. Zoidberg a écrit :
> Bonita Montero <Bonita....@gmail.com> wrote:
>
>> Using plain gdb is disgusting.
>
> The fact that you don't know how to do it doesn't make it disgusting.
>

gdb has an unusable user interface. That is a fact. No modern debugger
has such an interface like:

print whatever

over and over again!!!!!

Modern debuggers analyze the current line and automatically display the
relevant variables.

Modern debuggers display the source code when available and if it is
not, they either do not follow,into a function for which there is no
code, or they display automatically the disassembly. ONLY GDB will
display a blank screen!

Those "features" of gdb make it absolutely horrible, but there will be
always an arrogant gnu fan like you that will try to hide those flaws by
insulting people that complain about it.

Your comment is completely unjustified, and people have the right to
complain about a user interface that hasn't been developed since at
least 30 years!!!

You can't work with the gdb team since they do not even acknowledge the
bugs fixes you send.

You can keep your insult for yourself

[fir]

i personally dont need a debugger...
for those who will say i need it i could say i reaally dont need it (not saying that some improvements to editor would be of no help but in fuct i think i need more good editor functions)

i think primary rule is to code this way you dont get bugs in places other than those few lines you upwrite at the moment (and i realy rarely have that kind of bugs which i need to localize, reary rarely, i dot know once a 2 months of heavy coding?)

if such bug will appear i will localize it and it may tahe an hour or maybe even 2 but it hapens so rarely (once i year i could say that 2 hours of waste once a year is not a big waste)

i damn rarely have bugs at all (if compile erreors and typical line runig
excluded bugs dont see be of much existing problem

real problem is still teh same it is energy/exhaustion and (secondareley) need and troubles of proper conceptualisation (invention)

the more advanced i am i would say the less problem with bugs i have, maybe even the less problem with conceptualisation i have (not saying i feel a great force to invent and conceptualize great things, but i get
some force to do at leas decent one)
and the more problem with exhaustion(s) i have

even pure theoretical work like gets more exhausting to me - in fact this is not only an exhaustion but the lack of incentive (?) i feel..its like psyhe gets weary and im older and older

in such perspective discusion about debugger are kinda silly

[Bonita Montero]

> i personally dont need a debugger...

That's while you don't write code with noticeably complexity.

[Malcolm McLean]

On Friday, 17 July 2020 13:26:46 UTC+1, jacobnavia wrote:
>
> gdb has an unusable user interface. That is a fact. No modern debugger
> has such an interface like:
>
> print whatever
>
> over and over again!!!!!
>
> Modern debuggers analyze the current line and automatically display the
> relevant variables.
>
> Modern debuggers display the source code when available
>

A debugger really needs to be integrated into the IDE. Then you can step
through, tracing the path of execution in the source. Some even allow
interactive editing, though I've never adventured into that.

Also, you want a rich GUI to control your watch windows.

[fir]

W dniu piątek, 17 lipca 2020 19:15:30 UTC+2 użytkownik Bonita Montero napisał:
> > i personally dont need a debugger...
>
> That's while you don't write code with noticeably complexity.

thats why i agrevviate poor no-brain trolls like you and that kind of brain-lacking crowd

[fir]

ps maybe i used wrong word 'aggreviated' (weak english and i got not quite good ear for meaning of some words, i meant quite common psychological situation/effect when primitives get frustrated)

[fir]

i may add just for completion i met many imbeciles in my life but the records of heavy imbveciles belongs to usenet..here the density of extremaly pathological idiots and heavines of this pathology represented by common morons like ramine, dik, chad or bonita is the absolute top achivement of human stupidity

then people wonder why some people who have somethig to say not sit on this place of obvious medical pathology...seing this darknet of imbeciles its rather clear why