I'm trying debug application using GNU gdb that built by icc (Intel C compiler). But gdb not see any line in file (but if I build app using gcc everything fine).
I have never used before icc compiler so maybe I do something wrong. Please help :)
icc - Version 8.0
gdb - GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6)
OS - Red Hat Enterprise Linux Server release 6.8 (Santiago)
test.c:
1 #include<stdio.h>
2
3 int main(int argc, char **argv)
4 {
5 int count = 0;
6 while(1)
7 {
8 printf("Work In %d \n",count);
9 count++;
10 sleep(2);
11 }
12 }
Run build: icc -g -inline_debug_info --gsplit-dwarf ./test.c -o test
And when I tryied to break line (8 line for example) in gdb, gdb shows: No line 8 in file "./test.c"
Output:
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6)
Copyright (C) 2010 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 "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/test...done.
(gdb) break 8
No line 8 in file "./test.c".
Output:
080487e4 <main>: main(): /tmp/./test.c:4 ...
80487f0: 56 push %esi /tmp/./test.c:5
80487f1: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%ebp) /tmp/./test.c:6 ...
80487ff: 74 33 je 8048834 <main+0x50> /tmp/./test.c:8 ...
8048812: e8 41 fe ff ff call 8048658 <printf#plt>
This might be a confusion between test.c and ./test.c.
Does the picture change if you use icc -g test.c -o test instead?
(Using ./test.c is quite unusual and completely unnecessary.)
when I run a simple cmd in bash, I got:
$echo 12312> aaa.txt
-bash: 12312: Bad file descriptor
$lsof aaa.txt
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bash 20647 root 4r REG 8,1 0 1409118 aaa.txt
$bash --version
GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2011 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.
$uname -a
Linux node39 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
is a bug here? I'm not familiar with the bash source code, but I want to
know why. So please give me some tips,best wish to you.
edit:
thx to answer my question, but I really want to know why aaa.txt still opened by
bash after error happend.
spaces - bash is very specific about spaces
echo 1234 > output.txt
int the above example 1234 in written to output.txt using redirection operator >
on the other hand if you omit the spaces
echo 1234> output.txt
redirection operator will treat 1234 as "file descriptor number"
I was reading this article and was able to set the terminal interrupt character to o using stty intr o.
However, after the first time I used o, the interrupt character would get reset to ^C again.
How can I persist an intr setting on a given tty?
Update with more machine information.
$ bash --version
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2009 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.
$ uname -a
Linux <hostname_foobar> 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Update: This appears to only happen if I access to machine above over SSH. I have tested both with key-based login and with password-based login and it reproduces across both cases.
For this kernel version string (displayed on boot):
Linux version 3.12.18 (vagrant#vagrant-ubuntu-trusty-64) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #1 SMP Thu May 1 18:56:23 UTC 2014
How can the part in bold be removed or customized as part of the kernel build?
You can customize parts of your version string you wish to edit (seen at boot or by invoking the command cat /proc/version) by setting the following defines:
KBUILD_BUILD_USER to change your "vagrant" value.
KBUILD_BUILD_HOST to change your "vagrant-ubuntu-trusty-64" value.
You may also be interested in KBUILD_BUILD_TIMESTAMP (changes "Thu May 1 18:56:23 UTC 2014") and KBUILD_BUILD_VERSION (changes "#1").
The complete Linux process banner is finalized in init/version.c. The values of these defines are generated by scripts/mkcompile_h. You could edit either of these files to have full control of your version string, but you never know when this additional information might be helpful; I would recommend only altering the defines. Another option is to make some changes your host system to override generated values. By doing this, you're adding additional build maintenance just to change a rarely queried value.
Kernel provides the below info only to user-space via uname call. You can seegcc version gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) only in customized uname binary/kernel.
man 2 uname
struct utsname {
char sysname[]; /* Operating system name (e.g., "Linux") */
char nodename[]; /* Name within "some implementation-defined
network" */
char release[]; /* Operating system release (e.g., "2.6.28") */
char version[]; /* Operating system version */
char machine[]; /* Hardware identifier */
#ifdef _GNU_SOURCE
char domainname[]; /* NIS or YP domain name */
#endif
};
Fedora/Redhat does not display compiler information.
[root#Shash Sasi]# uname -a
Linux Shash 3.13.10-200.fc20.x86_64 #1 SMP Mon Apr 14 20:34:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
And vagrant#vagrant-ubuntu-trusty-64 looks like EXTRAVERSION is kernel main makefile.
VERSION = 3
PATCHLEVEL = 15
SUBLEVEL = 0
EXTRAVERSION = -rc3
In init/version.c:
const char linux_banner[] =
"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "#"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
const char linux_proc_banner[] =
"%s version %s"
" (" LINUX_COMPILE_BY "#" LINUX_COMPILE_HOST ")"
" (" LINUX_COMPILER ") %s\n";
Also refer fs/proc/version.c
It should be:
make menuconfig -> General setup -> Local version - append to kernel release
that is CONFIG_LOCALVERSION in the .config file.
When I type uname -a, it gives the following output.
Linux mars 2.6.9-67.0.15.ELsmp #1 SMP Tue Apr 22 13:50:33 EDT 2008 i686 i686 i386 GNU/Linux
How can I know from this that the given OS is 32 or 64 bit?
This is useful when writing configure scripts, for example: what architecture am I building for?
Try uname -m. Which is short of uname --machine and it outputs:
x86_64 ==> 64-bit kernel
i686 ==> 32-bit kernel
Otherwise, not for the Linux kernel, but for the CPU, you type:
cat /proc/cpuinfo
or:
grep flags /proc/cpuinfo
Under "flags" parameter, you will see various values: see "What do the flags in /proc/cpuinfo mean?"
Among them, one is named lm: Long Mode (x86-64: amd64, also known as Intel 64, i.e. 64-bit capable)
lm ==> 64-bit processor
Or using lshw (as mentioned below by Rolf of Saxony), without sudo (just for grepping the cpu width):
lshw -class cpu|grep "^ width"|uniq|awk '{print $2}'
Note: you can have a 64-bit CPU with a 32-bit kernel installed.
(as ysdx mentions in his/her own answer, "Nowadays, a system can be multiarch so it does not make sense anyway. You might want to find the default target of the compiler")
If you were running a 64 bit platform you would see x86_64 or something very similar in the output from uname -a
To get your specific machine hardware name run
uname -m
You can also call
getconf LONG_BIT
which returns either 32 or 64
lscpu will list out these among other information regarding your CPU:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
...
Another useful command for easy determination is as below:
Command:
getconf LONG_BIT
Answer:
32, if OS is 32 bit
64, if OS is 64 bit
The command
$ arch
is equivalent to
$ uname -m
but is twice as fast to type
I was wondering about this specifically for building software in Debian (the installed Debian system can be a 32-bit version with a 32 bit kernel, libraries, etc., or it can be a 64-bit version with stuff compiled for the 64-bit rather than 32-bit compatibility mode).
Debian packages themselves need to know what architecture they are for (of course) when they actually create the package with all of its metadata, including platform architecture, so there is a packaging tool that outputs it for other packaging tools and scripts to use, called dpkg-architecture. It includes both what it's configured to build for, as well as the current host. (Normally these are the same though.) Example output on a 64-bit machine:
DEB_BUILD_ARCH=amd64
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=amd64
DEB_BUILD_GNU_CPU=x86_64
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=x86_64-linux-gnu
DEB_HOST_ARCH=amd64
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=amd64
DEB_HOST_GNU_CPU=x86_64
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=x86_64-linux-gnu
You can print just one of those variables or do a test against their values with command line options to dpkg-architecture.
I have no idea how dpkg-architecture deduces the architecture, but you could look at its documentation or source code (dpkg-architecture and much of the dpkg system in general are Perl).
#include <stdio.h>
int main(void)
{
printf("%d\n", __WORDSIZE);
return 0;
}
If you have a 64-bit OS, instead of i686, you have x86_64 or ia64 in the output of uname -a. In that you do not have any of these two strings; you have a 32-bit OS (note that this does not mean that your CPU is not 64-bit).
That system is 32bit. iX86 in uname means it is a 32-bit architecture. If it was 64 bit, it would return
Linux mars 2.6.9-67.0.15.ELsmp #1 SMP Tue Apr 22 13:50:33 EDT 2008 x86_64 i686 x86_64 x86_64 GNU/Linux
Nowadays, a system can be multiarch so it does not make sense anyway. You might want to find the default target of the compiler:
$ cc -v 2>&1 | grep ^Target
Target: x86_64-pc-linux-gn
You can try to compile a hello world:
$ echo 'int main() { return 0; }' | cc -x c - -o foo
$ file foo
foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=b114e029a08abfb3c98db93d3dcdb7435b5bba0c, not stripped
With respect to the answer "getconf LONG_BIT".
I wrote a simple function to do it in 'C':
/*
* check_os_64bit
*
* Returns integer:
* 1 = it is a 64-bit OS
* 0 = it is NOT a 64-bit OS (probably 32-bit)
* < 0 = failure
* -1 = popen failed
* -2 = fgets failed
*
* **WARNING**
* Be CAREFUL! Just testing for a boolean return may not cut it
* with this (trivial) implementation! (Think of when it fails,
* returning -ve; this could be seen as non-zero & therefore true!)
* Suggestions?
*/
static int check_os_64bit(void)
{
FILE *fp=NULL;
char cb64[3];
fp = popen ("getconf LONG_BIT", "r");
if (!fp)
return -1;
if (!fgets(cb64, 3, fp))
return -2;
if (!strncmp (cb64, "64", 3)) {
return 1;
}
else {
return 0;
}
}
Good idea, the 'getconf'!
You can also check using a environment variable:
echo $HOSTTYPE
Result:
i386 -> 32 bits
x86_64 -> 64 bits
Extracted from: http://www.sysadmit.com/2016/02/linux-como-saber-si-es-32-o-64-bits.html
In Bash, using integer overflow:
if ((1 == 1<<32)); then
echo 32bits
else
echo 64bits
fi
It's much more efficient than invoking another process or opening files.
getconf uses the fewest system calls:
$ strace getconf LONG_BIT | wc -l
253
$ strace arch | wc -l
280
$ strace uname -m | wc -l
281
$ strace grep -q lm /proc/cpuinfo | wc -l
301
If you shift 1 left by 32 and you get 1, your system is 32 bit.
If you shift 1 left by 64 and you get 1, your system is 64 bit.
In other words,
if echo $((1<<32)) gives 1 then your system is 32 bit.
if echo $((1<<64)) gives 1 then your system is 64 bit.
If one is severely limited in available binaries (e.g. in initramfs), my colleagues suggested:
$ ls -l /lib*/ld-linux*.so.2
On my ALT Linux systems, i586 has /lib/ld-linux.so.2 and x86_64 has /lib64/ld-linux-x86-64.so.2.
$ grep "CONFIG_64" /lib/modules/*/build/.config
# CONFIG_64BIT is not set
I can't believe that in all this time, no one has mentioned:
sudo lshw -class cpu
to get details about the speed, quantity, size and capabilities of the CPU hardware.
Simple script to get 64 bit or 32 bit
if $(getconf LONG_BIT | grep '64'); then
echo "64 bit system"
else
echo "32 bit system"
fi
[ -z `uname -m | grep 64` ] && echo "32-bit" || echo "64-bit"
Based on the fact that 64-bit is usually x86_64 and 32-bit is i686 etc.
First you have to download Virtual Box. Then select new and a 32-bit Linux. Then boot the linux using it. If it boots then it is 32 bit if it doesn't then it is a 64 bit.