elf-objdump.exe已停止工作

非常经常地得到这个错误。在MPLAB内部，我得到错误255，它不生成十六进制/MAP，运行MPLAB之外的编译器“停止工作”，但它至少生成十六进制/MAP。



      以下为原文

    Getting this error very regularly. Inside of MPLAB, I get error #255 and it generates no hex/map, running the compiler outside of MPLAB I get "stopped working" but at least it generates a hex/map.

嗨，你应该通过一张票到Microchip报告，如果你想把这个固定在未来的版本。这是一个用户论坛。



      以下为原文

    Hi,
You should report this through a ticket to Microchip if you want to get this fixed in a future version.
This is a user forum.
Regards
 

大家好，我们最近发现这个问题与ObjDIP崩溃后的建设，并意识到它。我在星期三收到了一些报告，确定了原因和决议。这并没有真正帮助用户今天在那里！问题是闪存中有一些数据段（通常是包含数据的空间（PROG）或‘代码’汇编部分’）看起来像代码段，而检查器工具正在尝试评估代码（仅用于EP设备）。不幸的是，这是一个戏剧性的失败。好的新是，此时编译器和链接器已经完成了那里的工作，并且ELF文件就坐在它应该坐的地方（做进一步的构建-不干净和构建）应该允许MPLAB X找到并编程该设备。坏消息是，检查器工具无法检查此代码的安全性。我们发布了计划，并为V1.33计划了一个快速回合发布，这将是另一个支持发布的版本，包括一些bug修复，包括这一个。如果你对这个问题还有任何疑问，请给我一个私人信息，很乐意回答。



      以下为原文

    Hi all,
 
   We have recently discovered this issue with objdump crashing after the build and are aware of it.  I received some reports on Wednesday and have identified the cause and the resolution.  That doesn't really help users out there today!
 
   The issue is that there are some data sections in FLASH (typically space(prog) or 'code' assembly sections that contain data) that look like code sections and the checker tool is trying to evaluate the code (only for EP devices).  Unfortunately this fails in a dramatic way.
 
   The good new is that at this point the compiler and linker have finished there work, and an ELF file is sitting where it ought to sit (doing a further build - not clean and build) should allow MPLAB X to find it and program the device.  The bad news is that the checker tool is not able to check the safety of this code.
 
   We got off schedule with releases and are planning a quick-turn release for v1.33 which will be another part-support release with a number of bug fixes, including this one.
 
   If you have any further questions about this issue, please send me a private message and will be happy to respond.
 
Regards
Calum

嗨，Calum，我也发现了这个错误。我正在编写DSPIC33 EV256GM106代码，在TISISO中保留一些空间（对于引导加载程序），这会导致ELF对象在1.30和1.32 b中崩溃（显然它不只是受影响的1.32字节）。-代码中的Mconst（因为声明const而不初始化它总是将RAM中的const放在内存中）



      以下为原文

    Hi Calum,
i just discovered this error, too.
I am writing code for dsPIC33EV256GM106
doing this
volatile const __attribute__((space(prog),address(0x200))) uint16_t reserved_space[256]
to reserve some space (for a bootloader)
 
will cause elf-objdump to crash in both 1.30 and 1.32B (so apparently it's not just 1.32B that is affected)
 
a workaround will be to do as compiler manual suggests, add -mconst-in-code and
volatile const __attribute__((address(0x200))) uint16_t reserved_space[256] = {0,};
(because declaring the const without initializing it will always put the const in RAM)