| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
If the name field of a symbol table entry is all zero, it's interpreted
as it's pointing to the beginning of the string table. The first four
bytes of the string table is the size field, so dumpbin dumps that number
as an ASCIZ string.
This patch fills a dummy value to name field.
llvm-svn: 228971
|
|
|
|
|
|
|
| |
Symbols specified by --wrap was being inserted into a vector, change this to
insert into a set, so that we have unique entries.
llvm-svn: 228968
|
|
|
|
|
|
| |
We can add this function when we really have a need.
llvm-svn: 228907
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use a wrapper function for symbol. Any undefined reference to symbol will be
resolved to "__wrap_symbol". Any undefined reference to "__real_symbol" will be
resolved to symbol.
This can be used to provide a wrapper for a system function. The wrapper
function should be called "__wrap_symbol". If it wishes to call the system
function, it should call "__real_symbol".
Here is a trivial example:
void * __wrap_malloc (size_t c)
{
printf ("malloc called with %zu\n", c);
return __real_malloc (c);
}
If you link other code with this file using --wrap malloc, then all calls
to "malloc" will call the function "__wrap_malloc" instead. The call to
"__real_malloc" in "__wrap_malloc" will call the real "malloc" function.
llvm-svn: 228906
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the LinkingContext parameter to the ELFReader. Previously the flags in
that were needed in the Context was passed to the ELFReader, this made it very
hard to access data structures in the LinkingContext when reading an ELF file.
This change makes the ELFReader more flexible so that required parameters can be
grabbed directly from the LinkingContext.
Future patches make use of the changes.
There is no change in functionality though.
llvm-svn: 228905
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The dumpbin tool in the MSVC toolchain cannot handle an executable created
by LLD if the executable contains a long section name.
In PE/COFF, a section name is stored to a section table entry. Because the
section name field in the table is only 8 byte long, a name longer than
that is stored to the string table and the offset in the string table is
stored to the section table entry instead.
In order to look up a string from the string table, tools need to handle
the symbol table, because the string table is defined as it immediately
follows the symbol table.
And seems the dumpbin doesn't like zero-length symbol table.
This patch teaches LLD how to emit a dummy symbol table. The dummy table
has one dummy entry in it.
llvm-svn: 228900
|
|
|
|
| |
llvm-svn: 228887
|
|
|
|
|
|
|
| |
The fix is for r228680.
This makes tests also work.
llvm-svn: 228837
|
|
|
|
|
|
|
|
|
|
| |
When calling ARM code from Thumb and vice versa,
a veneer that switches instruction set should be generated.
Added veneer generation for ARM_JUMP24 ARM_THM_JUMP24 instructions.
Differential Revision: http://reviews.llvm.org/D7502
llvm-svn: 228680
|
|
|
|
|
|
|
| |
Differential Revision: D7489
Reviewed by: shankarke
llvm-svn: 228533
|
|
|
|
| |
llvm-svn: 228476
|
|
|
|
| |
llvm-svn: 228461
|
|
|
|
| |
llvm-svn: 228453
|
|
|
|
| |
llvm-svn: 228450
|
|
|
|
| |
llvm-svn: 228449
|
|
|
|
|
|
|
| |
It looks like the Driver manages search path for each Target lld would support
on the Gnu flavor.
llvm-svn: 228440
|
|
|
|
| |
llvm-svn: 228380
|
|
|
|
|
|
| |
No change in functionality.
llvm-svn: 228379
|
|
|
|
| |
llvm-svn: 228378
|
|
|
|
|
|
|
|
|
|
| |
After the total number of program headers are determined, virtual addresses
and file offsets need not be reassigned for sections whose virtual addresses and
fileoffsets remained the same.
This doesnot change any functionality.
llvm-svn: 228377
|
|
|
|
|
|
|
|
|
| |
Only search library directories explicitly specified
on the command line. Library directories specified in linker
scripts (including linker scripts specified on the command
line) are ignored.
llvm-svn: 228375
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we only have File::path() to get the path name of a file.
If a file was a member of an archive file, path() returns a concatenated
string of the file name in the archive and the archive file name.
If we wanted to get a file name or an archive file name, we had to
parse that string. That's of course not good.
This patch adds new member functions, archivePath and memberPath, to File.
http://reviews.llvm.org/D7447
llvm-svn: 228352
|
|
|
|
|
|
|
| |
Make customOrder pareamter mandatory because the argument is
always passed.
llvm-svn: 228342
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The real user of the LayoutPass is now only Mach-O, so move that
pass out of the common directory to Mach-O directory.
"Core" architecture were using the LayoutPass. I modified that
to use a simple OrderPass. I think no one actually have authority
what feature should be in Core and what's not, but I believe the
LayoutPass is not very suitable for Core. Before more code starts
depending on the complex pass, it's better to remove that from
Core.
I could have simplified that pass because Mach-O is the only user
of the LayoutPass. For example, the second parameter of the
LayoutPass constructor can be converted from optional to mandatory.
I didn't do that in this patch to keep it simple. I'll do in a
followup patch.
http://reviews.llvm.org/D7311
llvm-svn: 228341
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we incorrectly added the image base address to an absolute
symbol address (that calculation doesn't make any sense) if an
IMAGE_REL_I386_DIR32 relocation is applied to an absolute symbol.
This patch fixes the issue. With this fix, we can link Bochs using LLD.
(Choosing Bochs has no special meaining -- I just picked it up as a
test program and found it didn't work.) This also fixes one of the
issues we currently have to link Chromium using LLD.
llvm-svn: 228279
|
|
|
|
|
|
| |
The reader was discarding certain types of sections from the input file.
llvm-svn: 228268
|
|
|
|
|
|
| |
MemoryBuffer is being released too early. ELFFile owns MemoryBuffer.
llvm-svn: 228260
|
|
|
|
| |
llvm-svn: 228201
|
|
|
|
| |
llvm-svn: 228106
|
|
|
|
|
|
|
|
|
|
| |
This may be a little bit inefficient than the original code
but that should be okay as this is not really in a performance
critical pass.
http://reviews.llvm.org/D7393
llvm-svn: 228077
|
|
|
|
|
|
|
|
|
|
| |
INPUT directive is a variant of GROUP in the sense that that specifies
a list of input files. The only difference is whether the entire file
list is wrapped with a --start-group/--end-group or not.
http://reviews.llvm.org/D7390
llvm-svn: 228060
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, no one owns script::Parser buffers, but yet ELFLinkingContext gets
updated with StringRef pointers to data inside Parser buffers. Since this buffer
is locally owned inside GnuLdDriver::evalLinkerScript(), as soon as this
function finishes, all pointers in ELFLinkingContext that comes from linker
scripts get invalid. The problem is that we need someone to own linker scripts
data structures and, since ELFLinkingContext transports references to linker
scripts data, we can simply make it also own all linker scripts data.
Differential Revision: http://reviews.llvm.org/D7323
llvm-svn: 227975
|
|
|
|
|
|
|
|
|
|
| |
Added relocations to perform function calls with and without passing arguments.
ARM-only, Thumb-only and mixed mode code generations are supported.
Only simple veneers (direct instruction modification) are supported as ARM-Thumb interwork.
Differential Revision: http://reviews.llvm.org/D7223
llvm-svn: 227961
|
|
|
|
|
|
|
| |
Differential Revision: D7326
Reviewed by: rafaelauler, shankarke, ruiu
llvm-svn: 227786
|
|
|
|
|
|
|
|
| |
Target specific LinkingContext's determine the default search directory.
No change in functionality.
llvm-svn: 227784
|
|
|
|
| |
llvm-svn: 227707
|
|
|
|
|
|
|
| |
The .got and .got.plt sections are already handled as typeGOT. There is no need
to handle these atoms whose contentType is typeData.
llvm-svn: 227706
|
|
|
|
| |
llvm-svn: 227671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we applied the LayoutPass to order atoms and then
apply elf::ArrayOrderPass to sort them again. The first pass is
basically supposed to sort atoms in the normal fashion (which
is to sort symbols in the same order as the input files).
The second pass sorts atoms in {init,fini}_array.<priority> by
priority.
The problem is that the LayoutPass is overkill. It analyzes
references between atoms to make a decision how to sort them.
It's slow, hard to understand, and above all, it doesn't seem
that we need its feature for ELF in the first place.
This patch remove the LayoutPass from ELF pass list. Now all
reordering is done in elf::OrderPass. That pass sorts atoms by
{init,fini}_array, and if they are not in the special section,
they are ordered as the same order as they appear in the command
line. The new code is far easier to understand, faster, and
still able to create valid executables.
Unlike the previous layout pass, elf::OrderPass doesn't count
any attributes of an atom (e.g. permissions) except its
position. It's OK because the writer takes care of them if we
have to.
This patch changes the order of final output, although that's
benign. Tests are updated.
http://reviews.llvm.org/D7278
llvm-svn: 227666
|
|
|
|
| |
llvm-svn: 227534
|
|
|
|
| |
llvm-svn: 227526
|
|
|
|
|
|
|
| |
getAsInteger may partially update its result argument. We need to
check function return value to handle errors reliably.
llvm-svn: 227510
|
|
|
|
|
|
|
| |
No two atoms are allowed to have the same file and atom ordinals.
If there's such atoms, there's a bug in the reader.
llvm-svn: 227504
|
|
|
|
|
|
|
| |
_runLayoutPass is always true. No way to set a new value to the
member variable.
llvm-svn: 227501
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LayoutPass is one of the slowest pass. This change is to skip
that pass. This change not only improve performance but also improve
maintainability of the code because the LayoutPass is pretty complex.
Previously we used the LayoutPass to sort all atoms in a specific way,
and reorder them again for PE/COFF in GroupedSectionPass.
I spent time on improving and fixing bugs in the LayoutPass (e.g.
r193029), but the pass is still hard to understand and hard to use.
It's better not to depend on that if we don't need. For PE/COFF, we
just wanted to sort atoms in the same order as the file order in the
command line.
The feature we used in the LayoutPass is now simplified to
compareByPosition function in OrderPass.cpp. The function is just 5
lines.
This patch changes the order of final output because it changes the
sort order a bit. The output is still correct, though.
llvm-svn: 227500
|
|
|
|
| |
llvm-svn: 227410
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D7225
llvm-svn: 227320
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 227297
|
|
|
|
|
|
|
|
|
|
|
|
| |
That kind of reference was used only in ELFFile, and the use of
that reference there didn't seem to make sense. All test still
pass (after adjusting symbol names) without that code. LLD is
still be able to link LLD and Clang. Looks like we just don't
need this.
http://reviews.llvm.org/D7189
llvm-svn: 227259
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 227245
|