gdb调试产生code文件以及遇到的“file format not recognized”问题解决_file format not recognised

一、调试 core 文件的配置

1.1 开启core文件 —— ulimit

有时候，服务器程序运行一段时间后会突然崩溃，这并不是我们希望看到的，需要
解决这个问题。只要程序在崩溃的时候有 core 文件产生，就可以使用这个 core 文件
来定位崩溃的原因。当然，Linux 系统默认是不开启程序崩溃产生 core 文件这一机制
的，我们可以使用 ulimit -c 命令来查看系统是否开启了这一机制。发现 core file size 那一行默认是 0，表示关闭生成 core 文件。

如何开启
1）使用 ulimit -c unlimited （unlimited 是 -c 选项值）直接修改成不限制大小。
2）然后执行 source /etc/profile 即可立即生效。
3）再次查看 ulimit -c ，结果为 unlimited 表示修改成功。

1.2 设置core文件生成地址

系统默认 corefile 是生成在程序的执行目录下或者程序启动调用了 chdir 之后的目录。我们可以通过设置生成 corefile 的格式来控制它，让其生成在固定的目录下
1）打开/etc/sysctl.conf

sudo vim /etc/sysctl.conf
2）在文件最后，写入 corefile 文件生成的目录 
kernel.core_pattern=/home/zxm/codedump/core_%e_%p_%t

 %e 所dump的文件名
 %p 所dump的进程PID
 %t 转储时刻(由1970年1月1日起计的秒数) 
3）执行生效 
sudo sysctl -p /etc/sysctl.conf
4）使用 cat 去查看路径是否生效 
cat /proc/sys/kernel/core_pattern
1.3 测试
 
#include <stdio.h>
int main(void)
    printf("hello world! dump core for set value to NULL pointer/n");
    *(char *)0 = 0;
    return 0;
1）编译运行 
gcc -g -o core_dump core_dump.c
./core_dump
结果是Segmentation fault 
2）到/home/zxm/codedump，输入ll查看
 
 3）有core文件，使用 gdb 进行调试。从结果看，提示出错位置在第6行 
gdb ./core_dump /home/zxm/codedump/core_core_dump_2369_1689412339
1.4 无法产生code文件和file format not recognized报错
 
1）没有产生code文件
 一开始调试的时候，并没设置路径。因为默认是程序运行的目录下，但是执行后没有产生。
  
2）file format not recognized报错
 后面，设置的路径是/home/zxm/share/codedump，share是我的共享文件夹。这个时候报错 
"/home/zxm/share/coredump/core_core_dump_2186" is not a core dump: file format not recognized

 检查一下coredump，发现生成的code文件是0。那就是先前ulimit -c unlimited没设置成功。
 
 3）解决办法
 最后解决方法：不要把coredump创建在自己共享文件夹下。我这边修改到/home/zxm/codedump，再运行一次，就ok了；
 
 
                                    有时候， 程序core dump了， 但是没有生成core, 郁闷哈。
         有时候， 程序core dump了， 也产生了core文件， 但core大小为了0， gdb分析的时候， 会出现is not a core dump: File format not recognized， 此时应该打开ulimited -c  unlimited开关。
        有时候， 程序co
                                    今天，我用g++来编译一个文件时，出现了这种错误。要编译的源码文件名为test1_1。后来，我把文件名改为test1_1.cpp就可以正常编译了。这是怎么回事？？？
哎，原来是我傻逼了，原来GCC编译器套件对源代码的后缀是有要求的，它根据后缀来判断源码类型的。
   这是我查阅到的资料：
    GCC文件后缀名：
　　.c为后缀的文件，C语言源代码文件；
　　.a为后...
                                    linux环境下，C++编译出现问题，报错
XXX:file format not recognized; treating as linker script
XXX:syntax error
原因是，识别不了文件格式，只能将文件当作一个链接识别。出现该错误原因
很多，如果是cpp文件或者o文件，可以仔细检查一下文件名是否正确。若是文件名无误，可以使用file命令进一步排错。
以上错误发生后，查看了一下文件格式，发现so文件格式竟然变成了ASCII text;
而实际so文件格式应该为
实际上，以上错误一般
                                    近日，使用nlopt库（一个求最优解的C++库）时遇到的一个问题，已解决，与大家分享一下，并顺便作为自己的笔记吧（linux小白的学习笔记）。
首先，是调试时，代码写好后，在桌面编译器编译是没有问题的（用的是qt），正常输出结果。由于此代码最终需要在arm上运行，需要用交叉编译器进行编译，但是编译器一换到交叉编译器就报以下错误：
对于此报错一开始在网上搜了下，基本上可以确定是库识别不了的问题，由于代码的编写风格是C11的，这个交叉编译器是C99的，一开始以为是这样的问题，ok，按C99的风格改回来之后发
                                    刚开始学习Qt，在调试程序时提示not in executable format:file format not recognized
在查找资料后发现是因为编译器（Compiler）使用了32 位版本的 MSVC，调试器（Debugger）却使用了64 位的 MinGW 的 GDB，从而 GDB 不能调试 32 位程序而报错。
解决办法：
在 Qt 的 工具 - 选项 - 构建和运行 - Debuggers 选择 CDB（Debugging Tools for Windows），
不能自动检测到则手动添
                                    3.4 Debugging executables
If hell was a complicated program, you would certainly want to test and debug it before installing it on your system. In the above section, you saw how the libtool wrapper s
                                    最近写makefile,  碰到了nm: test.o: File format not recognized这个错误， 一起看看：
        test.h:
void output();        test.cpp:
#include 
#include "test.h"
void output()
	printf("c is good\n");
}         编译：
一、问题描述
linux环境下，C++编译出现问题，报错：
XXX.so:file format not recognized; treating as linker script
XXX.so:syntax error
原因是，识别不了文件格式，只能将文件当作一个链接识别
二、出错原因
以上错误发生后，查看了一下文件格式，发现.so文件格式变成了ASCII text：
而实际so文件格式应该为：
这个错误其实是因为我的整个开发环境是在windows下，而编译环