Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Currently taking an online course which provides VMWare Player with gdb. I'm using WinXP pro, Intel on a pc.
"strings" is a binary file, and my terminal is in the appropriate directory
Whenever I attempt debug with cmd '(gdb) r ./filename I get the following:
(gdb) r ./strings
Starting program: ./strings
No executable file specified.
Use the "file" or "exec-file" command.
Could someone explain what might be wrong to cause the above, and what I might do to correct it.
Also, how does one "use the 'file' or 'exec-file' command, if this will help solve the problem.
What might be addn'l info regarding this problem, the "make" cmd in my compiler runs:
"clang -ggdb3 -O0 -std=c99 -Wall -Werror" with some additional remarks.
Shiva cmds give following response on my terminal:
jharvard@appliance (~/src2w): [user@example]~$ ls -la /path/to/strings
bash: [user@example]~$: command not found
jharvard@appliance (~/src2w): [user@example]~$ chmod +x /path/to/strings
bash: [user@example]~$: command not found
>>>>>>>>>>>>>>
I don't really know what you mean by execution permission, but I can successfully write and run the code on the terminal.
L Root suggestions give the following terminal screen:
>>>>>>>>>>>
(gdb) ./strings: No such file or directory.
Undefined command: "". Try "help".
(gdb) (gdb) r
Undefined command: "". Try "help".
(gdb) Starting program:
Undefined command: "Starting". Try "help".
(gdb) No executable file specified.
(gdb) Use the "file" or "exec-file" command.
shivaa's example was just showing you the standard linux command prompt, you weren't supposed to actually run the "[user@example]~$" part. He even put it in green to separate it from the actual command. Many of the replies you receive on Linux forums will give some kind of command prompt in the replies. This separates the command you're supposed to run from the expected output from that command. For example, if I were to write:
Code:
date
Sat Feb 23 19:58:38 MST 2013
You wouldn't know what was the command vs what was the expected output. However, if I were to write:
Code:
$ date
Sat Feb 23 19:58:38 MST 2013
or
Code:
[user@example]~$ date
Sat Feb 23 19:58:38 MST 2013
You now know what was the command vs what was the expected output.
You need to run the command itself, "ls -la /path/to/strings" and "chmod +x /path/to/strings". Ignore the "[user@example]~$" since that's just an example command prompt.
Last edited by suicidaleggroll; 02-23-2013 at 09:09 PM.
@atlantis43:
Wait.. Wait... as suicidaleggroll mentioned, [user@example]~$: is NOT part of the original command(s). Its just prompt which I used in my example for clarity. And /path/to/strings means full path of the strings file, like /home/foo/bar/strings.
Anyway, you simply need to run following commands:
Code:
ls -la ./strings
chmod +x ./strings
And after this, run your gdb command like you were running before.
Quote:
A personal suggestion: Do not follow any post blindly. Read it, think about it, understand it, and if you feel it's safe to execute it, then only run it on your terminal. A wrong command may destroy your system in seconds, so beware of running any command without understanding it's purpose.
A personal suggestion: Do not follow any post blindly. Read it, think about it, understand it, and if you feel it's safe to execute it, then only run it on your terminal. A wrong command may destroy your system in seconds, so beware of running any command without understanding it's purpose.
Always good advice
While I've never seen a malcontent post on LinuxQuestions, blindly executing any command posted by a stranger, without understanding what you're running or why, is never a good thing.
While we're on the subject, it's about time to familiarize yourself with the "man" command. Man stands for "manual", and when run with the name of a command you're curious about, it will give you the manual of that command so you can see what it does, what the various switches are and what they do, etc.
For example, take the
Code:
$ ls -la ./strings
command presented earlier
Code:
$ man ls
will bring up the manual for ls. The first section is:
Code:
NAME
ls - list directory contents
SYNOPSIS
ls [OPTION]... [FILE]...
DESCRIPTION
List information about the FILEs
Then you can search for -l or -a to find out what those switches do (you search with "/", so to search for -l just type "/-l" and use "n" to step forward or "N" to step backward through the matches until you find the description for the -l flag:
Code:
-l use a long listing format
and
Code:
-a do not ignore entries starting with .
This lets you know that the
Code:
$ ls -la
command will print out the the contents of the file/directory you give it using long-listing format without ignoring any entries starting with . (files starting with "." are typically hidden from the ls output, like your typical Windows "hidden files".
Last edited by suicidaleggroll; 02-23-2013 at 09:31 PM.
thanks to all for clarifications. none of the suggestions given seem to help, though perhaps I don't fully understand them. [I am correctly listed as a novice :-)]
I know that there is program 'strings.c' (compiled) and 'strings' (binary), both present in file ~/src2w/filename. -ls shows both files present where they're supposed to be. Still doesn't explain why gdb can't execute them.
Shivaa;
running your suggestions on code named "factorial", I get following results:
>>>>>>>>>>>>>>>
jharvard@appliance (~): ls -la ~/src2w/*factorial*
-rwx------. 1 jharvard students 10642 Feb 22 10:56 /home/jharvard/src2w/factorial
-rw-r--r--. 1 jharvard students 332 Feb 22 09:05 /home/jharvard/src2w/factorial.c
>>>>>>>>>>>>>>>>>
(what are those asterisks for, anyway)
then, when gdb run on this file:
>>>>>>>>>>>>
(gdb) r ./factorial
Starting program: ./factorial
No executable file specified.
Use the "file" or "exec-file" command.
>>>>>>>>>>>>>>
I've gotten this result previously, have looked in the man for file cmd, etc, but don't have the understanding of what the info means.
In addition, now having looked at the manual with a little better understanding, I get the following info about the file:
>>>>>>>>>>
jharvard@appliance (~/src2w): file factorial
factorial: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped
Hope this helps further in determining what my problem is.
Last edited by atlantis43; 02-24-2013 at 07:55 AM.
The OP is apparently not giving correct commands to gdb. That fact has been buried in this thread by all the focus on checking whether the executable file is valid. There is no reason to believe anything is wrong with the file.
You can specify the executable to be debugged on the command line that starts gdb, or you can specify it with a file command inside gdb. But you cannot specify it as a parameter to the r command in gdb.
OK, so I did the following (with no evident results, though I didn't know what to expect)
jharvard@appliance (~): chmod a+x /home/jharvard/src2w/factorial
jharvard@appliance (~): chmod a+x /home/jharvard/src2w/factorial.c
and then did:
(gdb) No executable file specified.
(gdb) Use the "file" or "exec-file" command.
Undefined command: "Use". Try "help".
Johnsfine attention to detail indeed worked. lroot's 2-liner was the answer, and I now have GDB working.
Don't understand why I have to run gdb in this fashion (as compared to what was given in the course's online instructions), but perhaps the link to the gdb documentation will answer that.
Only remaining question is whether I will have to use that format for engageing gdb for each program I might want to debug?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.