雖然試圖生成彙編代碼(混合源代碼),objdump的/ GCC - BFD:矮錯誤:使用objdump的錯位行數部
gcc -g -c test.c ;
objdump -S -M intel test.o > out.asm
我得到以下錯誤。
BFD: Dwarf Error: mangled line number section.
生成的輸出程序集不與源代碼混合。有人能澄清這是什麼意思?有沒有什麼辦法解決這一問題 ?
雖然試圖生成彙編代碼(混合源代碼),objdump的/ GCC - BFD:矮錯誤:使用objdump的錯位行數部
gcc -g -c test.c ;
objdump -S -M intel test.o > out.asm
我得到以下錯誤。
BFD: Dwarf Error: mangled line number section.
生成的輸出程序集不與源代碼混合。有人能澄清這是什麼意思?有沒有什麼辦法解決這一問題 ?
「objdump的-S -M」顯然是希望在.o文件將一個「.debug_abbrev節」部分,‘GCC -g’顯然不是寫它:
我不認爲有你可以做的任何事情(你已經使用「-g」來包含調試符號)。我認爲完全可以忽略。
違規包是「binutils」。下面是完整的代碼:
http://opensource.apple.com/source/binutils/binutils-20/src/bfd/dwarf2.c
/* In DWARF version 2, the description of the debugging information is
stored in a separate .debug_abbrev section. Before we read any
dies from a section we read in all abbreviations and install them
in a hash table. */
static struct abbrev_info**
read_abbrevs (abfd, offset)
bfd * abfd;
unsigned int offset;
{
struct abbrev_info **abbrevs;
char *abbrev_ptr;
struct abbrev_info *cur_abbrev;
unsigned int abbrev_number, bytes_read, abbrev_name;
unsigned int abbrev_form, hash_number;
struct dwarf2_debug *stash;
stash = elf_tdata(abfd)->dwarf2_find_line_info;
if (! stash->dwarf_abbrev_buffer)
{
asection *msec;
msec = bfd_get_section_by_name (abfd, ".debug_abbrev");
if (! msec)
{
(*_bfd_error_handler) (_("Dwarf Error: Can't find .debug_abbrev section."));
bfd_set_error (bfd_error_bad_value);
return 0;
}
此問題通常顯示編碼問題.debug_line部分造成連接器(LD)重新定位表的問題 - 重疊的內存拷貝。工具鏈需要錯誤修復和重建。
它不會影響程序加載和運行,但由於地址/符號不匹配,此問題將導致調試不可能。這裏是一個例子,代碼在0x0038ca82處被破壞(在糟糕的連接器情況下)。
0038ca80 00 = op_code = DW_LNS_extended_op
0038ca81 05 = op length = 5 bytes
0038ca82 02 = extended_op_code = DW_LNE_set_address
0038ca83 nn nn nn nn = 4-byte address
在有問題地鏈接的ELF,擴展操作碼(32未定義)
0038ca82 32 = extended_op_code = Unknown -> mangled line number section
問題LD導致ELF(錯位行號部分):
0038ca60 62 6c 69 63 2e 68 00 01 00 00 68 65 61 70 5f 6d |blic.h....heap_m|
0038ca70 67 72 5f 70 75 62 6c 69 63 2e 68 00 02 00 00 00 |gr_public.h.....|
0038ca80 00 05 32 00 40 18 02 94 32 00 40 00 01 01 00 05 |[email protected]@.....|
0038ca90 02 94 32 00 40 00 01 01 00 05 02 94 32 00 40 00 |[email protected]@.|
0038caa0 01 01 00 05 32 00 40 15 02 b0 32 00 40 00 01 01 |[email protected]@...|
0038cab0 00 05 02 b0 32 00 40 00 01 01 00 05 02 b0 32 00 |[email protected]|
0038cac0 40 00 01 01 00 05 02 c0 32 00 40 94 00 05 40 17 |@[email protected]@.|
普通LD導致ELF:
0038ca60 62 6c 69 63 2e 68 00 01 00 00 68 65 61 70 5f 6d |blic.h....heap_m|
0038ca70 67 72 5f 70 75 62 6c 69 63 2e 68 00 02 00 00 00 |gr_public.h.....|
0038ca80 00 05 02 80 32 00 40 38 00 05 02 80 32 00 40 18 |[email protected]@.|
0038ca90 00 05 02 90 32 00 40 1a 00 05 02 94 32 00 40 00 |[email protected]@.|
0038caa0 01 01 00 05 02 a0 32 00 40 49 00 05 02 a0 32 00 |[email protected]|
0038cab0 40 15 00 05 02 ac 32 00 40 15 00 05 02 b0 32 00 |@[email protected]|
0038cac0 40 00 01 01 00 05 02 c0 32 00 40 94 00 05 02 c0 |@[email protected]|
與源的混合代碼不起作用,當我得到這個錯誤。有沒有修復它? – Jean
是:使用「gcc -S」生成組件而不是objdump。 – paulsm4