public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Liang Cheng <liang.cheng555@gmail.com>
To: Triple Yang <triple.yang@gmail.com>
Cc: Hui Zhu <teawater@gmail.com>, gdb@sourceware.org
Subject: Re: command-list does not work in my gdb 7.2 port
Date: Fri, 30 Sep 2011 18:15:00 -0000	[thread overview]
Message-ID: <CAEU25CYQehnKwA7taa+gy1KXmBKbso5qHU3xk-1WpiBSHaq79w@mail.gmail.com> (raw)
In-Reply-To: <CAGxstLRjx42vR6-TYnpfXL1BgZ57BupnbgpVNrqix+nhAxr7Ag@mail.gmail.com>

He probably means you can try the latest gdb release as he did not see
such an issue.

On Tue, Sep 27, 2011 at 2:06 AM, Triple Yang <triple.yang@gmail.com> wrote:
> sorry, I do not understand what you are trying to say.
>
> 2011/9/27 Hui Zhu <teawater@gmail.com>:
>> (gdb) b mainBreakpoint 1 at 0x40056c: file 1.c, line 3.(gdb) commands
>> Type commands for breakpoint(s) 1, one per line.End with a line saying
>> just "end".>shell echo 123>end(gdb) rStarting program:
>> /home/teawater/gdb/a.out
>> Breakpoint 1, main () at 1.c:33 {123
>> Please try the trunk.
>>
>> Best,
>> Hui
>> https://code.google.com/p/gdbt/
>>
>> On Mon, Sep 26, 2011 at 22:58, Triple Yang <triple.yang@gmail.com> wrote:
>>> Hi, everyone.
>>>
>>> I am making a gdb 7.2 port recently for a prototype architecture,
>>> which is a remote debug target in my case. The port is almost done to
>>> achieve my purposes, say:
>>>
>>> 1. Connecting to remote target and loading program image work well.
>>> 2. Control on the debugged program is OK.
>>> 3. Inserting/deleting breakpoints OK.
>>> 4. and so as some other basic facilities.
>>>
>>> But when I tried using gdb command "commands" to specify a command
>>> list after I set a breakpoint, I found this did not work at all. Here
>>> follows a rough example:
>>>
>>> (gdb) break main
>>> (gdb) commands
>>>>shell echo test-commands
>>>>end
>>> (gdb) run
>>>
>>> In this example, the command list is composed of only one command
>>> "shell echo test-commands". "test-commands" is expected to be output
>>> when the breakpoint is hit, but it does not happen. I tried replacing
>>> "shell echo test-commands" with other similar commands, it still did
>>> not work. but "shell echo" does work well when it is not used in a
>>> command list defined by "commands".
>>>
>>> I am not able to find any clue for this situation. Still worse, I can
>>> not provide sufficient information to gdb experts for analysis.
>>>
>>> I am hoping that someone who has ever met this problem before can help
>>> me with his/her invaluable suggestions.
>>>
>>> Thank you and best regards.
>>>
>>> --
>>> Yang Yong-Yong
>>>
>>
>
>
>
> --
> Yang Yong-Yong
>

  reply	other threads:[~2011-09-30 18:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-26 14:58 Triple Yang
2011-09-27  6:19 ` Hui Zhu
2011-09-27  7:07   ` Triple Yang
2011-09-30 18:15     ` Liang Cheng [this message]
2011-10-01  5:34       ` Triple Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEU25CYQehnKwA7taa+gy1KXmBKbso5qHU3xk-1WpiBSHaq79w@mail.gmail.com \
    --to=liang.cheng555@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=teawater@gmail.com \
    --cc=triple.yang@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).