[Bug cli/24494] New: inferior execution command changes between consecutive runs

[gabriel at krisman dot be]

https://sourceware.org/bugzilla/show_bug.cgi?id=24494

            Bug ID: 24494
           Summary: inferior execution command changes between consecutive
                    runs
           Product: gdb
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: cli
          Assignee: unassigned at sourceware dot org
          Reporter: gabriel at krisman dot be
  Target Milestone: ---

When debugging a program that requires an environment parameter, the following
syntax works on the first run, but will fail on the following runs, because the
command line gets messed up:

> gdb -q --args env HELLO=WOLRD ls /bla

Full log: 

[krisman@dilma ~]$ gdb -q --args env HELLO=WORLD ls bla
Reading symbols from env...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/env HELLO=WORLD ls bla
process 5304 is executing new program: /bin/ls
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
dir1  file1  file2
[Inferior 1 (process 5304) exited normally]
(gdb) r
Starting program: /bin/ls HELLO=WORLD ls bla
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
/bin/ls: cannot access 'HELLO=WORLD': No such file or directory
/bin/ls: cannot access 'ls': No such file or directory
bla:
dir1  file1  file2
[Inferior 1 (process 5319) exited with code 02]
(gdb) 

Note that when the first 'run' command is executed, the command line used to
start the inferior is correct.  On the second run, it is incorrect.

I understand this might not be the canonical way to pass an environment
variable when running a program inside gdb, but it is a convenient way to do
so.

-- 
You are receiving this mail because:
You are on the CC list for the bug.