I have an OBJ with 2c1 sections. How can I dump the header of only section 101?
dumpbin /HEADERS /SECTION:101 file.obj gives me the whole list. The same thing as dumpbin /HEADERS file.obj with the added line:
LINK : warning LNK4039: section '101' specified with /SECTION option does not exist
But it does:
SECTION HEADER #101
.rdata name
0 physical address
0 virtual address
10 size of raw data
11A9C file pointer to raw data (00011A9C to 00011AAB)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40301040 flags
Initialized Data
COMDAT; sym= EP_Commands
4 byte align
Read Only
The /SECTION documentation doesn't help. Geoff say's the section name is case sensitive. I have tried decimal numbers. I have tried hex numbers. I have tried #101. I have tried sect101.
You are using section number instead of section name. Here is the command-line to get the details of only the above section you have mentioned in your question:
dumpbin /HEADERS /SECTION:.rdata file.obj
Related
I'm learning ELF, and was given a task to create a custom READELF program in C 32bit linux.
As part of my task, I created pointers to the '.symtab' and the '.strtab' tables, so I could print each symbol name. However, when comparing my output to the original READELF output, I noticed that I'm missing the "#..." part after some of the symbol names.
Where can I find this data?
I was inspecting the preprocessed output generated by GCC, and I see a lot of these in the .i file that I generated using the -save-temps flag:
# 8 "/usr/include/i386-linux-gnu/gnu/stubs.h" 2 3 4
What do the numbers before and after the absolute path of stubs.h mean? It seems to be some kind of debugging information that is inserted by the preprocessor and allows the compiler to issue error messages referring to this information. These lines do not affect the program itself, but what specifically is each number for?
Based on the documentation the number before the filename is the line number. The numbers after the file name are a flag and mean the following:
1 indicates the start of a new file.
2 indicates returning to a file (after having included another file).
3 indicates that the following text comes from a system header file, so certain warnings should be suppressed.
4 indicates that the following text should be treated as being wrapped in an implicit extern "C" block.
The test is on 32-bit Linux, x86.
Suppose in my assembly program final.s, I have to load some library symbols, say, stdin##GLIBC_2.0, and I want to load these symbols in a fixed address.
So following instructions in this question, I did this:
echo ""stdin##GLIBC_2.0" = 0x080a7390;" > symbolfile
echo ""stdin#GLIBC_2.0 (4)" = 0x080a7390;" >> symbolfile
gcc -Wl,--just-symbols=symbolfile final.s -g
And when I checked the output of symbol table, I got this:
readelf -s a.out | grep stdin
53: 080a7390 4 OBJECT GLOBAL DEFAULT ABS stdin##GLIBC_2.0
17166: 080a7390 0 NOTYPE GLOBAL DEFAULT ABS stdin#GLIBC_2.0 (4)
And comparing to a common ELF biary that requires stdin symbol:
readelf -s hello.out | grep stdin
17199: 0838b8c4 4 OBJECT GLOBAL DEFAULT 25 stdin##GLIBC_2.0
52: 0838b8c4 4 OBJECT GLOBAL DEFAULT 25 stdin#GLIBC_2.0 (4)
So an obvious difference I found is that the Ndx column, say, the section number of my fixed position symbols are ABS. Please check the references here.
When executing the a.out, it throws a segmentation fault error.
So my question is, how to set the section number of the symbol fixed position?
I want to load these symbols in a fixed address.
You are importing these symbols from GLIBC. Unless you are doing a fully-static linking, you get no say in what address these symbols end up at.
So my question is, how to set the section number of the symbol
That question makes no sense: section number itself is meaningless and 25 may refer to .bss in one executable, but to .text in another.
Your section 25 just happens to be .bss on this particular system and for this particular build. Try building a fully-static binary, and you are likely to see section 24 instead.
Anyway, a normal executable gets stdin copied from libc.so.6. You will do well to read this description of the process, and pay special attention to "Extra credit #2: Referencing shared library data from the executable" section.
But it may be easier to understand the fully-static case first.
Due to a bug in ld I need to copy an ELF section from one object file to another. I can dump the desired section to a file but the problem is that objcopy's --add-section option expects a binary file and the section type information is therefore lost. As far as I can tell I cannot set the type of a section using binutils but I'm hoping I'm wrong :)
I can edit the binary manually to set the section type and that
solves the underlying problem, but I'm curious as to whether there's a solution based on standard tools.
For the curious the underlying problem is that when GNU ld links an
ARM object file without the .ARM.attributes section (such as a file
with just a binary blob living in its own section) it picks some
default that causes it to generate invalid veneers to RAM-functions
even when the files containing the calls have good .ARM.attributes
sections. The only solution (pending
https://sourceware.org/bugzilla/show_bug.cgi?id=11897) that I can come up with is to add a .ARM.attributes section to the binary-blob object file. However, that only works if the .ARM.attributes section has the type ARM_ATTRIBUTES.
In an LD linker script I have the following fragment in the SECTIONS section:
. = (__BUFFER_LOCATION_);
BUFFER . : { } > EXTERNAL_MEM
where __BUFFER_LOCATION_ is defined to some address and EXTERNAL_MEM is defined in the MEMORY section.
In the C program, I have a global buffer declared as:
char outbuf[4096] __attribute__((section("BUFFER")));
It can be seen that the linker script does not mention any input section named BUFFER, but the output section is named as such.
When compiling the program I see that the linker placed the buffer in the supposed address (BUFFER_LOCATION), although the input section was not defined in the LDF. When I remove the attribute from the source, the buffer is placed in a completely different address.
So, I assume that by default, an output-section-command of type "input section description" adds the output section's name to the input sections list implicitly, unless defined somewhere else. However, reading the manual, I could not find a description of such behaviour.
Did I miss something, or is it an "undocumented feature"?
Yes, an output section will automatically match input sections with the same name, unless a different output section mentions them explicitly.
This is documented under Orphan Sections (emphasis mine):
Orphan sections are sections present in the input files which are not explicitly placed into the output file by the linker script. The
linker will still copy these sections into the output file by either
finding, or creating a suitable output section in which to place the
orphaned input section.
If the name of an orphaned input section exactly matches the name of
an existing output section, then the orphaned input section will be
placed at the end of that output section.
If there is no output section with a matching name then new output
sections will be created...