llvm-svn: 171363

llvm-svn: 171341

llvm-svn: 171305

llvm-svn: 171304

llvm-svn: 171302

llvm-svn: 171301

llvm-svn: 171300

llvm-svn: 171299

On MachO, sections also have segment names. When a tool looking at a .o file
prints a segment name, this is what they mean. In reality, a .o has only one
anonymous, segment.

This patch adds a MachO only function to fetch that segment name. I named it
getSectionFinalSegmentName since the main use for the name seems to be inform
the linker with segment this section should go to.

The patch also changes MachOObjectFile::getSectionName to return just the
section name instead of computing SegmentName,SectionName.

The main difference from the previous patch is that it doesn't use
InMemoryStruct. It is extremely dangerous: if the endians match it returns
a pointer to the file buffer, if not, it returns a pointer to an internal buffer
that is overwritten in the next API call.

We should change all of this code to use
support::detail::packed_endian_specific_integral like ELF, but since these
functions only handle strings, they work with big and little endian machines
as is.

I have tested this by installing ubuntu 12.10 ppc on qemu, that is why it took
so long :-)

llvm-svn: 170838

http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056754.html

The proposal and implementation are fully documented here:
https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/aligned-bundling-support-in-llvm

Tests will follow shortly.

llvm-svn: 170718

its only user, is gone.

llvm-svn: 170699

llvm-svn: 170578

llvm-svn: 170547

I cannot reproduce it the failures locally, so I will keep an eye at the ppc
bots. This patch does add the change to the "Disassembly of section" message,
but that is not what was failing on the bots.

Original message:

Add a funciton to get the segment name of a section.

On MachO, sections also have segment names. When a tool looking at a .o file
prints a segment name, this is what they mean. In reality, a .o has only one
anonymous, segment.

This patch adds a MachO only function to fetch that segment name. I named it
getSectionFinalSegmentName since the main use for the name seems to be infor
the linker with segment this section should go to.

The patch also changes MachOObjectFile::getSectionName to return just the
section name instead of computing SegmentName,SectionName.

llvm-svn: 170545

the assembler.

Part of PR14624

llvm-svn: 170390

compilation directory.

This defaults to the current working directory, just as it always has,
but now an assembler can choose to override it with a custom directory.
I've taught llvm-mc about this option and added a test case.

llvm-svn: 170371

Mips16 is really a processor decoding mode (ala thumb 1) and in the same
program, mips16 and mips32 functions can exist and can call each other.

If a jal type instruction encounters an address with the lower bit set, then
the processor switches to mips16 mode (if it is not already in it). If the
lower bit is not set, then it switches to mips32 mode.

The linker knows which functions are mips16 and which are mips32.
When relocation is performed on code labels, this lower order bit is
set if the code label is a mips16 code label.

In general this works just fine, however when creating exception handling
tables and dwarf, there are cases where you don't want this lower order
bit added in.

This has been traditionally distinguished in gas assembly source by using a
different syntax for the label.

lab1:      ; this will cause the lower order bit to be added
lab2=.     ; this will not cause the lower order bit to be added

In some cases, it does not matter because in dwarf and debug tables
the difference of two labels is used and in that case the lower order
bits subtract each other out.

To fix this, I have added to mcstreamer the notion of a debuglabel.
The default is for label and debug label to be the same. So calling
EmitLabel and EmitDebugLabel produce the same result.

For various reasons, there is only one set of labels that needs to be
modified for the mips exceptions to work. These are the "$eh_func_beginXXX" 
labels.

Mips overrides the debug label suffix from ":" to "=." .

This initial patch fixes exceptions. More changes most likely
will be needed to DwarfCFException to make all of this work
for actual debugging. These changes will be to emit debug labels in some
places where a simple label is emitted now.

Some historical discussion on this from gcc can be found at:
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00623.html
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01273.html 

llvm-svn: 170279

This reverts commit r170095 since it appears to be breaking the bots.

llvm-svn: 170105

On MachO, sections also have segment names. When a tool looking at a .o file
prints a segment name, this is what they mean. In reality, a .o has only one,
anonymous, segment.

This patch adds a MachO only function to fetch that segment name. I named it
getSectionFinalSegmentName since the main use for the name seems to be informing
the linker with segment this section should go to.

The patch also changes MachOObjectFile::getSectionName to return just the
section name instead of computing SegmentName,SectionName.

llvm-svn: 170095

llvm-svn: 169817

llvm-svn: 169812

The linker will call `lto_codegen_add_must_preserve_symbol' on all globals that
should be kept around. The linker will pretend that a dylib is being created.
<rdar://problem/12528059>

llvm-svn: 169770

llvm-svn: 169724

llvm-svn: 169720

This function sets the `_exportDynamic' ivar. When that's set, we export all
symbols (e.g. we don't run the internalize pass). This is equivalent to the
`--export-dynamic' linker flag in GNU land:

--export-dynamic
  When creating a dynamically linked executable, add all symbols to the dynamic
  symbol table. The dynamic symbol table is the set of symbols which are visible
  from dynamic objects at run time. If you do not use this option, the dynamic
  symbol table will normally contain only those symbols which are referenced by
  some dynamic object mentioned in the link. If you use dlopen to load a dynamic
  object which needs to refer back to the symbols defined by the program, rather
  than some other dynamic object, then you will probably need to use this option
  when linking the program itself.

The Darwin linker will support this via the `-export_dynamic' flag. We should
modify clang to support this via the `-rdynamic' flag.

llvm-svn: 169656

It was a nasty oversight that we didn't include this when we added this
API in the first place. Blech.

rdar://12839439

llvm-svn: 169653

Quick build fix for c++03 clang. This needs a proper solution. Note that these offsets are guaranteed to be correct by Endian.h.

llvm-svn: 169438

The new command line option -unwind-info dumps the Win64 EH unwind
data to the console. This is a nice feature if you need to debug
generated EH data (e.g. from LLVM). Includes a test case.

Initial patch by João Matos, extensions and rework by Kai Nacke.

llvm-svn: 169415

This is for the lldb team so most of but not all of the values are
to be printed as hex with this option.  Some small values like the
scale in an X86 address were requested to printed in decimal
without the leading 0x.

There may be some tweaks need to places that may still be in
decimal that they want in hex.  Specially for arm.  I made my best
guess.  Any tweaks from here should be simple.

I also did the best I know now with help from the C++ gurus
creating the cleanest formatImm() utility function and containing
the changes.  But if someone has a better idea to make something
cleaner I'm all ears and game for changing the implementation.

rdar://8109283

llvm-svn: 169393

Again, tools are trickier to pick the main module header for than
library source files. I've started to follow the pattern of using
LLVMContext.h when it is included as a stub for program source files.

llvm-svn: 169252

This causes llc to repeat the module compilation N times, making it
possible to get more accurate information from -time-passes when
compiling small modules.

llvm-svn: 169040

depends on the IR infrastructure, there is no sense in it being off in
Support land.

This is in preparation to start working to expand InstVisitor into more
special-purpose visitors that are still generic and can be re-used
across different passes. The expansion will go into the Analylis tree
though as nothing in VMCore needs it.

llvm-svn: 168972

start up and clean up module passes, now that ASAN and TSAN are fixed the
tests pass

llvm-svn: 168905

This is for backwards compatibility for pre-3.x bc files. The code reads the
code, but does nothing with it.

llvm-svn: 168779

The functionality of SectionMemoryManager is equivalent to the LLIMCJITMemoryManager being replaced except that it allocates memory as RW and later changes it to RX or R as needed.  The page permissions are set in the call to MCJIT::finalizeObject.

llvm-svn: 168722

The dependent libraries feature was never used and has bit-rotted. Remove it.

llvm-svn: 168694

llvm-svn: 168665

Revert r168635 "Step towards implementation of pass manager with doInitialization and doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model".
It appears to have broken at least one buildbot.

llvm-svn: 168654

Step towards implementation of pass manager with doInitialization and doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model

Patch by Pedro Artigas, with feedback from by Chandler Carruth.

llvm-svn: 168635

Necessary to give disassembler users (like darwin's otool) a possibility to
dlopen libLTO and still initialize the required LLVM bits. This used to go
through libMCDisassembler but that's a gross layering violation, the MC layer
can't pull in functions from the targets. Adding a function to libLTO is a bit
of a hack but not worse than exposing other disassembler bits from libLTO.

Fixes PR14362.

llvm-svn: 168545