BDM elf 文件与普通 elf 文件

发布于 2024-09-10 04:04:08 字数 650 浏览 8 评论 0原文

就内存使用而言,BDM ELF 文件比普通 ELF 文件有什么优势?

我对两者都了解以下几点:

  1. BDM ELF 文件可用于通过任何调试器工具进行调试 类似于 Trace32,通过插入 JTAG。普通的ELF文件也可以 用于调试目的,前提是我们有相应的 FLS 文件(闪存文件),必须闪存到ROM区域 细胞外基质。
  2. BDM ELF 文件被加载到 ECM(电子 Control Module),而普通的 ELF 文件及其相应的 FLS 被加载到 ECM 的 ROM 区域中。
  3. ELF 文件(BDM 或普通文件)未完整加载 进入ECM的内存(我从ECM的大小来理解这一点 我们用于加载 ELF 的内存(以 KB 为单位) 与 ELF 的巨大尺寸(以 MB 为单位)相比, ELF 文件的某些部分(如类型、变量和 函数等)保存在 Trace32 内存中。

以上是我对使用ELF的主要理解,我知道如果我理解错误的话,你们会帮助我纠正自己。

我的期望是了解 BDM ELF 文件内容如何在 Trace32 调试器和 ECM 内存之间分布,两种 ELF 格式如何比另一种更有优势,因为两者都仅用于调试目的。请注意,在向客户发布应用程序/软件时,我们会以客户闪存到其 ECM 中的 FLS 格式进行发布。

如果您需要更多信息来继续回答我的问题,请告诉我。

Whats the advantage that the BDM ELF file has over the normal ELF file in terms of memory used?

I know the following things about both:

  1. BDM ELF file could be used for debugging through any debugger tools
    like Trace32 by plugging in JTAG. The normal ELF file also can be
    used for debugging purpose, provided we have the corresponding FLS
    file (Flash file) that has to be flashed into the ROM area of the
    ECM.
  2. BDM ELF files are loaded into the RAM area of the ECM (Electronic
    Control Module) whereas the normal ELF files and their corresponding
    FLS are loaded into the ROM are of the ECM.
  3. The ELF files (either BDM or the normal one) are not loaded entire
    into the memory of ECM (I understood this from the size of the ECM
    memory that we use for loading the ELF which is in terms of KB's
    compared to the huge size of the ELF which is in terms of MB's),
    some part of the ELF file (symbols like types, variabled and
    functions etc) are kept with the Trace32 memory.

The above were my major understandings of using the ELF's, I know that you people will help me in correcting myself in case I have interpreted anything wrongly.

My expectation is to understand how is BDM ELF file content distributed among the Trace32 debugger and the ECM memory, how is either of the ELF formats advantageous than one another as both are used for debugging purpose only. Please note that when it come to releasing the application/software to the customer, we release in terms of the FLS format which the customer flash into their ECM.

Please let me know if you need anymore information to proceed with answering my question.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

妄想挽回 2024-09-17 04:04:08

好的,我再试一次:

BDM ​​ELF 文件内容如何在 Trace32 调试器和 ECM 内存之间分布?

ELF 文件可以保存调试符号信息(将内存位置和寄存器与函数和变量相关),trace32 使用这些信息来帮助您进行调试。该符号信息保存在trace32中,用于解码芯片的BDM输出(主要是寄存器值)并提供超出裸汇编的有用信息。

两种 ELF 格式如何
双方都比对方有利
仅用于调试目的?

这取决于您的调试工具和开发工具链。正如我在另一个答案中所说,ELF只是一种标准格式。它是否用于线路编程取决于您的开发工具在链接时的功能。由于您没有告诉我您的工具链是什么,所以我只能猜测。

如果您的设备具有扁平内存模型和集成 ROM(大多数 32 位设备具有较小的存储量),则只需要一个文件即可对设备进行编程。由于 RAM 和内部闪存的寻址相同,因此地址只需与所需的目的地匹配即可。

另一方面,如果您有两个存储 ROM 的位置(我怀疑您的产品就是这种情况)并且它们的寻址方式不同,则可能需要两个文件。如果有一个 ECU 与外部闪存 ROM 芯片(或 SD 卡等)连接,就会出现这种情况。在这种情况下,需要一个单独的图像来写入片外存储,因为地址可能会重叠(ELF 假设一段数据有一个唯一的地址)。因此,在您的情况下,需要两个 ELF 文件:一个指定要加载到 RAM 中以在调试中启动设备的调试设置,另一个指定操作系统的符号信息和编程到外部闪存芯片中的其他数据。 FLS 文件可能指定程序员用来寻址 ELF 中不存在的外部闪存的信息,但这取决于体系结构(我不熟悉诺基亚如何设计其硬件)。

这可能对一般 ELF 信息有帮助: http://blog.ksplice.com/tag/elf/< /a>

OK, I'll try again:

How is BDM ELF file content distributed among the Trace32 debugger and the ECM memory?

The ELF file can hold debugging symbol information (relating memory locations and registers to functions and variables), which the trace32 uses to help you debug. This symbol information is held in trace32 and it is used to decode the BDM output from the chip (register values, mostly) and provide useful information beyond bare assembly.

How is either of the ELF formats
advantageous than one another as both
are used for debugging purpose only?

This depends on your debugging tool and your development tool chain. As I said in my other answer, ELF is just a standard format. Weather it is used for line programming depends on what your development tool does at link time. Since you don't tell me what your tool chain is, I can really only speculate.

If your device has a flat memory model and integrated ROM (most 32-bit devices with smaller amounts of storage), then only a single file is necessary to program the device. Since RAM and internal flash are addressed the same, the address just needs to match the desired destination.

If, on the other hand, you have two places where ROM is stored (which I suspect is the case in your product) and they aren't addressed the same, then two files might be necessary. This would be the case if there were an ECU which interfaced with and external flash ROM chip (or SD card or the like). In this case, a separate image would be required to write to the off-chip storage since the addresses would likely overlap (an ELF assumes a unique address for a piece of data). So in your case, two ELF files are needed: one specifies the debugging setup to be loaded into RAM to start the device in debug, the other specifies the symbol information for the OS and other data programmed into the external flash chip. The FLS files probably specify information that the programmer uses to address the external flash not present in the ELF, but this depends on architecture (I'm not familiar with how Nokia designs their hardware).

This may help for general ELF info: http://blog.ksplice.com/tag/elf/

尸血腥色 2024-09-17 04:04:08

BDM ELF 的功能是在代码运行时查看内存位置和内存映射寄存器的更改,而无需停止代码。

通过使用 BDM ELF,我们可以拥有硬件观察点或断点。这很有用,因为您可以在更改值时中断而不影响执行速度。一旦调试器中断,我们可以使用“调试内核和应用程序一起”方法来准确查找发生故障的行。

您无法通过 BDM 调试器在用户程序中设置断点。这是因为它插入了“halt”指令,并且这些指令只能由内核代码执行。可以修改 BDM 驱动程序以允许通过 BDM 接口调试用户应用程序。

The ability of the BDM ELF is to view changes to memory locations, and memory-mapped registers while the code is running, and without having to stop it.

By using the BDM ELF we can have hardware watch points or breakpoints. This is useful as you can break on a value being changed without affecting the speed of execution. Once the debugger breaks we can use the Debugging Kernel and Applications together method for finding exactly which line it happened.

You cannot set breakpoints in user programs from the BDM debugger. This is because it inserts "halt" instructions and these can only be executed by kernel code. It is possible to modify the BDM driver to allow the debugging of user applications via the BDM interface.

溺深海 2024-09-17 04:04:08

你的问题没有问号。因此,我不确定我是否完全回答了您的问题。

此信息主要源自 BDM 上 ELF 文件的使用,而不是实际情况
文档:

ELF 是一种文件规范,因此所有 ELF 文件应该相同。 ELF 文件由链接器生成,包含符号信息以及组织成节的可执行代码。当用户对 ECM 进行编程时,调试器/编程器会读取 ELF 文件,挑选出各节的地址及其相关代码,然后根据需要写入这些内容。

可执行文件是否写入RAM或ROM取决于ELF中各节的地址(通常通过链接器读取的配置文件进行配置)或程序“编程”时程序员的设置。大多数调试器都可以选择将映像加载到 ROM 或 RAM。程序映像中的唯一区别是代码和变量的位置。

在您描述的情况下,您的程序员似乎无法从 elf 文件中提取可执行数据。我假设您的 fls 文件是某种原始图像文件,可以逐字写入目标硬件。

Your question lacks any question marks. As such, I'm not sure I'm fully answering what you are asking.

This information is largely derived from use of ELF files over BDM, not from actual
documentation:

ELF is a file specification, so all ELF files should be the same. The ELF file is generated by the linker, and contains symbol information as well as executable code organized into sections. When the user programs an ECM, the debugger/programmer reads through the ELF file, picks out addresses of sections and their associated code, then writes these as desired.

Whether the executable is written to RAM or ROM depends on either the addresses of the sections in the ELF (usually configurable via a config file read by the linker) or the settings of the programmer when the program is "programmed". Most debuggers have an option to load an image to either ROM or RAM. The only difference in the program images is the locations of code and variables.

In the situation that you describe, your programmer seems to not be able to pull the executable data from the elf file. I assume that your fls file is some sort of raw image file that can be written word for word to the target hardware.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文