- c - 在位数组中找到第一个零
- linux - Unix 显示有关匹配两种模式之一的文件的信息
- 正则表达式替换多个文件
- linux - 隐藏来自 xtrace 的命令
我的问题是关于 bfd 以及节数在以下代码中的工作方式。 bfd 结构的 gdb 调试器中的代码和转储及其内部的部分结构如下所示。我还在下面包含了 bfd 和 bfd-> 部分的数据结构定义。我的问题是:为什么当我运行此代码(可执行文件称为 getsections)时:getsections getsections.o(因此将目标文件传递给它本身)-为什么部分结构为空(全为零),如果您查看 bfd->section_count,它的编号是 4218960?如果您使用 Linux 命令:objdump -h getsections.o,它会显示 14 个部分(.text、.data、.bss、.rodata、.debug_info、.debug_abbrev、.debug_loc、.debug_aranges、.debug_line、.debug_str、.注释、.comment.SUSE.OPTS、.note-GNU-stack、.eh_frame)。我已经阅读了我可以在网络上的 BFD 文档中找到的内容,但我不确定我在这里做错了什么,因为我的目标文件结构与您在 objdump 中看到的结构(14 个部分)相去甚远。任何帮助表示赞赏。谢谢。
unsigned int number_of_sections(bfd *abfd)
{
unsigned int numSections = 0;
numSections = bfd_count_sections(abfd);
return numSections;
}
int main (int argc, char *argv[])
{
bfd *ibfd = NULL;
char filename[80];
char *fptr = &filename[0];
unsigned int numSections = 0;
if (argc < 2)
{
printf("Argc < 2\n");
exit(EXIT_FAILURE);
}
else
{
bfd_init();
printf("filename = %s\n", argv[1]);
ibfd = bfd_openr(argv[1], NULL);
numSections = number_of_sections(ibfd);
printf("num sections = %d\n", numSections);
bfd_close(ibfd);
}
return 1;
}
在 number_of_sections() 处设置断点,bfd 的转储产生以下内容:
(gdb) print abfd
$1 = (bfd *) 0x85c010
(gdb) print *abfd
$2 = {filename = 0x0, xvec = 0x7fffffffe06f, iostream = 0x7fff20 <bfd_elf64_x86_64_vec> "\211\345X", cacheable = (unknown: 8773984), target_defaulted = false, lru_prev = 0x7f6d40 <cache_iovec>, lru_next = 0x85c010, where = 8765456, opened_once = false, mtime_set = false, mtime = 0, ifd = 0, format = bfd_unknown, direction = read_direction, flags = 0, origin = 0, output_has_begun = false, sections = 0x85d180, section_count = 4218960, start_address = 8769872, symcount = 251, outsymbols = 0x130, arch_info = 0x0, arelt_data = 0x0, my_archive = 0x0, next = 0x0, archive_head = 0x0, has_armap = false, link_next = 0x0, archive_pass = 8673856, tdata = {aout_data = 0x0, aout_ar_data = 0x0, oasys_obj_data = 0x0, oasys_ar_data = 0x0, coff_obj_data = 0x0, pe_obj_data = 0x0, xcoff_obj_data = 0x0, ecoff_obj_data = 0x0, ieee_data = 0x0, ieee_ar_data = 0x0, srec_data = 0x0, tekhex_data = 0x0, elf_obj_data = 0x0, nlm_obj_data = 0x0, bout_data = 0x0, sun_core_data = 0x0, trad_core_data = 0x0, som_data = 0x0, hpux_core_data = 0x0, hppabsd_core_data = 0x0, sgi_core_data = 0x0, lynx_core_data = 0x0, osf_core_data = 0x0, cisco_core_data = 0x0, versados_data = 0x0, any = 0x0}, usrdata = 0x0, memory = {chunk_size = 0, chunk = 0x0, object_base = 0x0, next_free = 0x0, chunk_limit = 0x0, temp = {tempint = 0, tempptr = 0x0}, alignment_mask = 0, chunkfun = 0x85c140, freefun = 0x7, extra_arg = 0x21, use_extra_arg = 0, maybe_empty_object = 0, alloc_failed = 0}}
abfd-> 部分的转储看起来什么也没有:
(gdb) print *(abfd->sections)
$4 = {name = 0x0, index = 0, next = 0x0, flags = 0, vma = 0, user_set_vma = false, lma = 0, _cooked_size = 0, _raw_size = 0, output_offset = 0, output_section = 0x0, alignment_power = 0, relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 0, rel_filepos = 0, line_filepos = 0, userdata = 0x0, contents = 0x0, lineno = 0x0, lineno_count = 0, moving_line_filepos = 0, target_index = 0, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x0, reloc_done = false, symbol = 0x0, symbol_ptr_ptr = 0x0, link_order_head = 0x0, link_order_tail = 0x0}
bfd 结构如下:
struct _bfd
{
/* The filename the application opened the BFD with. */
CONST char *filename;
/* A pointer to the target jump table. */
const struct bfd_target *xvec;
/* To avoid dragging too many header files into every file that
includes `<<bfd.h>>', IOSTREAM has been declared as a "char
*", and MTIME as a "long". Their correct types, to which they
are cast when used, are "FILE *" and "time_t". The iostream
is the result of an fopen on the filename. */
char *iostream;
/* Is the file descriptor being cached? That is, can it be closed as
needed, and re-opened when accessed later? */
boolean cacheable;
/* Marks whether there was a default target specified when the
BFD was opened. This is used to select which matching algorithm
to use to choose the back end. */
boolean target_defaulted;
/* The caching routines use these to maintain a
least-recently-used list of BFDs */
struct _bfd *lru_prev, *lru_next;
/* When a file is closed by the caching routines, BFD retains
state information on the file here: */
file_ptr where;
/* and here: (``once'' means at least once) */
boolean opened_once;
/* Set if we have a locally maintained mtime value, rather than
getting it from the file each time: */
boolean mtime_set;
/* File modified time, if mtime_set is true: */
long mtime;
/* Reserved for an unimplemented file locking extension.*/
int ifd;
/* The format which belongs to the BFD. (object, core, etc.) */
bfd_format format;
/* The direction the BFD was opened with*/
enum bfd_direction {no_direction = 0,
read_direction = 1,
write_direction = 2,
both_direction = 3} direction;
/* Format_specific flags*/
flagword flags;
/* Currently my_archive is tested before adding origin to
anything. I believe that this can become always an add of
origin, with origin set to 0 for non archive files. */
file_ptr origin;
/* Remember when output has begun, to stop strange things
from happening. */
boolean output_has_begun;
/* Pointer to linked list of sections*/
struct sec *sections;
/* The number of sections */
unsigned int section_count;
/* Stuff only useful for object files:
The start address. */
bfd_vma start_address;
/* Used for input and output*/
unsigned int symcount;
/* Symbol table for output BFD (with symcount entries) */
struct symbol_cache_entry **outsymbols;
/* Pointer to structure which contains architecture information*/
const struct bfd_arch_info *arch_info;
/* Stuff only useful for archives:*/
PTR arelt_data;
struct _bfd *my_archive; /* The containing archive BFD. */
struct _bfd *next; /* The next BFD in the archive. */
struct _bfd *archive_head; /* The first BFD in the archive. */
boolean has_armap;
/* A chain of BFD structures involved in a link. */
struct _bfd *link_next;
/* A field used by _bfd_generic_link_add_archive_symbols. This will
be used only for archive elements. */
int archive_pass;
/* Used by the back end to hold private data. */
union
{
struct aout_data_struct *aout_data;
struct artdata *aout_ar_data;
struct _oasys_data *oasys_obj_data;
struct _oasys_ar_data *oasys_ar_data;
struct coff_tdata *coff_obj_data;
struct pe_tdata *pe_obj_data;
struct xcoff_tdata *xcoff_obj_data;
struct ecoff_tdata *ecoff_obj_data;
struct ieee_data_struct *ieee_data;
struct ieee_ar_data_struct *ieee_ar_data;
struct srec_data_struct *srec_data;
struct tekhex_data_struct *tekhex_data;
struct elf_obj_tdata *elf_obj_data;
struct nlm_obj_tdata *nlm_obj_data;
struct bout_data_struct *bout_data;
struct sun_core_struct *sun_core_data;
struct trad_core_struct *trad_core_data;
struct som_data_struct *som_data;
struct hpux_core_struct *hpux_core_data;
struct hppabsd_core_struct *hppabsd_core_data;
struct sgi_core_struct *sgi_core_data;
struct lynx_core_struct *lynx_core_data;
struct osf_core_struct *osf_core_data;
struct cisco_core_struct *cisco_core_data;
struct versados_data_struct *versados_data;
PTR any;
} tdata;
/* Used by the application to hold private data*/
PTR usrdata;
/* Where all the allocated stuff under this BFD goes */
struct obstack memory;
};
bfd->sections 结构(sec 结构)如下所示:
typedef struct sec
{
/* The name of the section; the name isn't a copy, the pointer is
the same as that passed to bfd_make_section. */
CONST char *name;
/* Which section is it; 0..nth. */
int index;
/* The next section in the list belonging to the BFD, or NULL. */
struct sec *next;
/* The field flags contains attributes of the section. Some
flags are read in from the object file, and some are
synthesized from other information. */
flagword flags;
#define SEC_NO_FLAGS 0x000
/* Tells the OS to allocate space for this section when loading.
This is clear for a section containing debug information
only. */
#define SEC_ALLOC 0x001
/* Tells the OS to load the section from the file when loading.
This is clear for a .bss section. */
#define SEC_LOAD 0x002
/* The section contains data still to be relocated, so there is
some relocation information too. */
#define SEC_RELOC 0x004
#if 0 /* Obsolete ? */
#define SEC_BALIGN 0x008
#endif
/* A signal to the OS that the section contains read only
data. */
#define SEC_READONLY 0x010
/* The section contains code only. */
#define SEC_CODE 0x020
/* The section contains data only. */
#define SEC_DATA 0x040
/* The section will reside in ROM. */
#define SEC_ROM 0x080
/* The section contains constructor information. This section
type is used by the linker to create lists of constructors and
destructors used by <<g++>>. When a back end sees a symbol
which should be used in a constructor list, it creates a new
section for the type of name (e.g., <<__CTOR_LIST__>>), attaches
the symbol to it, and builds a relocation. To build the lists
of constructors, all the linker has to do is catenate all the
sections called <<__CTOR_LIST__>> and relocate the data
contained within - exactly the operations it would peform on
standard data. */
#define SEC_CONSTRUCTOR 0x100
/* The section is a constuctor, and should be placed at the
end of the text, data, or bss section(?). */
#define SEC_CONSTRUCTOR_TEXT 0x1100
#define SEC_CONSTRUCTOR_DATA 0x2100
#define SEC_CONSTRUCTOR_BSS 0x3100
/* The section has contents - a data section could be
<<SEC_ALLOC>> | <<SEC_HAS_CONTENTS>>; a debug section could be
<<SEC_HAS_CONTENTS>> */
#define SEC_HAS_CONTENTS 0x200
/* An instruction to the linker to not output the section
even if it has information which would normally be written. */
#define SEC_NEVER_LOAD 0x400
/* The section is a COFF shared library section. This flag is
only for the linker. If this type of section appears in
the input file, the linker must copy it to the output file
without changing the vma or size. FIXME: Although this
was originally intended to be general, it really is COFF
specific (and the flag was renamed to indicate this). It
might be cleaner to have some more general mechanism to
allow the back end to control what the linker does with
sections. */
#define SEC_COFF_SHARED_LIBRARY 0x800
/* The section is a common section (symbols may be defined
multiple times, the value of a symbol is the amount of
space it requires, and the largest symbol value is the one
used). Most targets have exactly one of these (which we
translate to bfd_com_section_ptr), but ECOFF has two. */
#define SEC_IS_COMMON 0x8000
/* The section contains only debugging information. For
example, this is set for ELF .debug and .stab sections.
strip tests this flag to see if a section can be
discarded. */
#define SEC_DEBUGGING 0x10000
/* The contents of this section are held in memory pointed to
by the contents field. This is checked by
bfd_get_section_contents, and the data is retrieved from
memory if appropriate. */
#define SEC_IN_MEMORY 0x20000
/* End of section flags. */
/* The virtual memory address of the section - where it will be
at run time. The symbols are relocated against this. The
user_set_vma flag is maintained by bfd; if it's not set, the
backend can assign addresses (for example, in <<a.out>>, where
the default address for <<.data>> is dependent on the specific
target and various flags). */
bfd_vma vma;
boolean user_set_vma;
/* The load address of the section - where it would be in a
rom image; really only used for writing section header
information. */
bfd_vma lma;
/* The size of the section in bytes, as it will be output.
contains a value even if the section has no contents (e.g., the
size of <<.bss>>). This will be filled in after relocation */
bfd_size_type _cooked_size;
/* The original size on disk of the section, in bytes. Normally this
value is the same as the size, but if some relaxing has
been done, then this value will be bigger. */
bfd_size_type _raw_size;
/* If this section is going to be output, then this value is the
offset into the output section of the first byte in the input
section. E.g., if this was going to start at the 100th byte in
the output section, this value would be 100. */
bfd_vma output_offset;
/* The output section through which to map on output. */
struct sec *output_section;
/* The alignment requirement of the section, as an exponent of 2 -
e.g., 3 aligns to 2^3 (or 8). */
unsigned int alignment_power;
/* If an input section, a pointer to a vector of relocation
records for the data in this section. */
struct reloc_cache_entry *relocation;
/* If an output section, a pointer to a vector of pointers to
relocation records for the data in this section. */
struct reloc_cache_entry **orelocation;
/* The number of relocation records in one of the above */
unsigned reloc_count;
/* Information below is back end specific - and not always used
or updated. */
/* File position of section data */
file_ptr filepos;
/* File position of relocation info */
file_ptr rel_filepos;
/* File position of line data */
file_ptr line_filepos;
/* Pointer to data for applications */
PTR userdata;
/* If the SEC_IN_MEMORY flag is set, this points to the actual
contents. */
unsigned char *contents;
/* Attached line number information */
alent *lineno;
/* Number of line number records */
unsigned int lineno_count;
/* When a section is being output, this value changes as more
linenumbers are written out */
file_ptr moving_line_filepos;
/* What the section number is in the target world */
int target_index;
PTR used_by_bfd;
/* If this is a constructor section then here is a list of the
relocations created to relocate items within it. */
struct relent_chain *constructor_chain;
/* The BFD which owns the section. */
bfd *owner;
boolean reloc_done;
/* A symbol which points at this section only */
struct symbol_cache_entry *symbol;
struct symbol_cache_entry **symbol_ptr_ptr;
struct bfd_link_order *link_order_head;
struct bfd_link_order *link_order_tail;
} asection ;
最佳答案
我没有试过你的程序。但是,我注意到它不调用 bfd_check_format。这是必需的。 BFD 文档在这些方面并不总是很清楚(欢迎改进!)所以当我需要处理 BFD 时,我通常最终会阅读示例程序,例如 objdump。
我的一个 BFD 测试开始了:
fd = open (argv[1], O_RDONLY | O_CLOEXEC, 0);
if (fd == -1)
die ("open");
abfd = bfd_fopen (argv[1], NULL, "r", fd);
if (!bfd_check_format (abfd, bfd_object))
{
bfd_close (abfd);
die ("bfd_check_format");
}
关于c - 使用 bfd 数据结构的目标文件中的节数,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/22158487/
我目前正在尝试基于哈希表构建字典。逻辑是:有一个名为 HashTable 的结构,其中包含以下内容: HashFunc HashFunc; PrintFunc PrintEntry; CompareF
如果我有一个指向结构/对象的指针,并且该结构/对象包含另外两个指向其他对象的指针,并且我想删除“包含这两个指针的对象而不破坏它所持有的指针”——我该怎么做这样做吗? 指向对象 A 的指针(包含指向对象
像这样的代码 package main import "fmt" type Hello struct { ID int Raw string } type World []*Hell
我有一个采用以下格式的 CSV: Module, Topic, Sub-topic 它需要能够导入到具有以下格式的 MySQL 数据库中: CREATE TABLE `modules` ( `id
通常我使用类似的东西 copy((uint8_t*)&POD, (uint8_t*)(&POD + 1 ), back_inserter(rawData)); copy((uint8_t*)&PODV
错误 : 联合只能在具有兼容列类型的表上执行。 结构(层:字符串,skyward_number:字符串,skyward_points:字符串)<> 结构(skyward_number:字符串,层:字符
我有一个指向结构的指针数组,我正在尝试使用它们进行 while 循环。我对如何准确初始化它并不完全有信心,但我一直这样做: Entry *newEntry = malloc(sizeof(Entry)
我正在学习 C,我的问题可能很愚蠢,但我很困惑。在这样的函数中: int afunction(somevariables) { if (someconditions)
我现在正在做一项编程作业,我并没有真正完全掌握链接,因为我们还没有涉及它。但是我觉得我需要它来做我想做的事情,因为数组还不够 我创建了一个结构,如下 struct node { float coef;
给定以下代码片段: #include #include #define MAX_SIZE 15 typedef struct{ int touchdowns; int intercepti
struct contact list[3]; int checknullarray() { for(int x=0;x<10;x++) { if(strlen(con
这个问题在这里已经有了答案: 关闭 11 年前。 Possible Duplicate: Empty “for” loop in Facebook ajax what does AJAX call
我刚刚在反射器中浏览了一个文件,并在结构构造函数中看到了这个: this = new Binder.SyntaxNodeOrToken(); 我以前从未见过该术语。有人能解释一下这个赋值在 C# 中的
我经常使用字符串常量,例如: DICT_KEY1 = 'DICT_KEY1' DICT_KEY2 = 'DICT_KEY2' ... 很多时候我不介意实际的文字是什么,只要它们是独一无二的并且对人类读
我是 C 的新手,我不明白为什么下面的代码不起作用: typedef struct{ uint8_t a; uint8_t* b; } test_struct; test_struct
您能否制作一个行为类似于内置类之一的结构,您可以在其中直接分配值而无需调用属性? 前任: RoundedDouble count; count = 5; 而不是使用 RoundedDouble cou
这是我的代码: #include typedef struct { const char *description; float value; int age; } swag
在创建嵌套列表时,我认为 R 具有对列表元素有用的命名结构。我有一个列表列表,并希望应用包含在任何列表中的每个向量的函数。 lapply这样做但随后剥离了列表的命名结构。我该怎么办 lapply嵌套列
我正在做一个用于学习目的的个人组织者,我从来没有使用过 XML,所以我不确定我的解决方案是否是最好的。这是我附带的 XML 文件的基本结构:
我是新来的 nosql概念,所以当我开始学习时 PouchDB ,我找到了这个转换表。我的困惑是,如何PouchDB如果可以说我有多个表,是否意味着我需要创建多个数据库?因为根据我在 pouchdb
我是一名优秀的程序员,十分优秀!