search for: readerwriter

...t's essentially impossible. I think some serious >>> cleanup is needed here. >>> > >>> > Let's start with the purely link-level dependencies encoded in the >>> CMake build: >>> > >>> > Curently the Core library depends on the ReaderWriter/Native library, >>> which links against the ReaderWriter library, which links against the Core >>> library. This clearly cannot work. The same cycle exists with Core -> YAML >>> -> ReaderWrite -> Core. >>> How are you determining these cycles? How is C...

...LLD's libraries today > and found that it's essentially impossible. I think some serious cleanup is > needed here. > > > > Let's start with the purely link-level dependencies encoded in the CMake > build: > > > > Curently the Core library depends on the ReaderWriter/Native library, > which links against the ReaderWriter library, which links against the Core > library. This clearly cannot work. The same cycle exists with Core -> YAML > -> ReaderWrite -> Core. > How are you determining these cycles? How is Core dependent on YAML? > (cau...

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\concrt.h(313): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc (C:\lld-x86_64_win7\lld-x86_64-win7\llvm.src\tools\lld\lib\ReaderWriter\ELF\Hexagon\HexagonLinkingContext.cpp) [C:\lld-x86_64_win7\lld-x86_64-win7\llvm.obj\tools\lld\lib\ReaderWriter\ELF\Hexagon\lldHexagonELFTarget.vcxproj] C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\concrt.h(313): warning C4530: C++ exception handler used, but unwind semantics ar...

I wanted to go through and map out the layering of LLD's libraries today and found that it's essentially impossible. I think some serious cleanup is needed here. Let's start with the purely link-level dependencies encoded in the CMake build: Curently the Core library depends on the ReaderWriter/Native library, which links against the ReaderWriter library, which links against the Core library. This clearly cannot work. The same cycle exists with Core -> YAML -> ReaderWrite -> Core. The situation seems a bit worse for includes. If you start from LinkingContext.h I think this beco...

Hi, I'm analysing the LLD code structure (aka architecture) and am trying to mold it into a component model. Currently I see 4 components: - Driver - ReaderWriter - Passes - Core I wonder if this is the order that they're supposed to be in, since there are also code dependencies upwards from: Core -> ReaderWriter Passes -> ReaderWriter ReaderWriter -> Driver For a graphical view check: http://c2lang.org/docs/lld_architecture_96e1b5e02.pn...

...shankare at codeaurora.org>wrote: > C:\Program Files (x86)\Microsoft Visual Studio > 11.0\VC\include\concrt.h(313): warning C4530: C++ exception handler used, > but unwind semantics are not enabled. Specify /EHsc > (C:\lld-x86_64_win7\lld-x86_**64-win7\llvm.src\tools\lld\** > lib\ReaderWriter\ELF\Hexagon\**HexagonLinkingContext.cpp) > [C:\lld-x86_64_win7\lld-x86_**64-win7\llvm.obj\tools\lld\** > lib\ReaderWriter\ELF\Hexagon\**lldHexagonELFTarget.vcxproj] > C:\Program Files (x86)\Microsoft Visual Studio > 11.0\VC\include\concrt.h(313): warning C4530: C++ exception handler use...

Hi, I am trying to add a PowerPC/GNU LLD builder. Therefore I am building manually until everything is fine and I can link the builder into Zorg. It almost completed but then I got this error: [ 97%] Building CXX object tools/lld/lib/ReaderWriter/ELF/X86_64/CMakeFiles/lldX86_64ELFTarget.dir/X86_64LinkingContext.cpp.o /home/buildbot/buildbot/llvm-trunk/tools/lld/lib/ReaderWriter/ELF/X86_64/X86_64LinkingContext.cpp: In member function ‘virtual llvm::ArrayRef<unsigned char> {anonymous}::X86_64InitAtom::rawContent() const’: /home/buildbot...

Hi, I've been following the changes in LLD's software architecture. Recently a new file was added: Alias.h In this file, the curret Atom set is extended with an AliasAtom. While the change seems innocent enough, it has some nasty potential. Simple.h and Alias.h are placed in the ReaderWriter component. This is the 2nd component in the layering: Driver ReaderWriter Passes Core The problem is that Core depends on these files. So in my opinion, they belong to that Component. The greater impact here is that once core starts depending on ReaderWriter, architecture Erosion will happen. This...

The inverted dependency of Core to ReaderWriter via Simple.h was already present. My idea was to fix the problem before it gets bigger. My proposal would be to move Simple.h and Alias.h to Core. Similar to UndefinedAtom.h etc. It would be even nicer to make the naming consistent as well, since there already is UndefinedAtom.h SharedLibaryAtom.h...

...Rui Ueyama <ruiu at google.com> wrote: > I agree to move these files to Core. Any objections? None here. - Michael Spencer > > On Mon, Jun 2, 2014 at 12:44 AM, Bas van den Berg > <b.van.den.berg.nl at gmail.com> wrote: >> >> The inverted dependency of Core to ReaderWriter via Simple.h was already >> present. >> My idea was to fix the problem before it gets bigger. >> My proposal would be to move Simple.h and Alias.h to Core. Similar to >> UndefinedAtom.h etc. >> It would be even nicer to make the naming consistent as well, since there &...

I've run a new scan of LLD's architecture and it appears to be getting cleaner! There are still some upward dependencies however: - core depends on Reader and Writer - passes depend on Reader and Writer - ReaderWriter/PECOFF/ReaderCOFF.cpp depends on Driver.h The updated architecture can be seen here: http://www.c2lang.org/docs/lld_architecture_20140710.png On Tue, Jun 3, 2014 at 3:07 AM, Rui Ueyama <ruiu at google.com> wrote: > I will create a patch to move the files and send it for review. > &g...

...a crash in lld when using linker script with wildcard matching. An example linker script: INPUT(os/main.o os/foo.o os/startup.o) OUTPUT(k.bin) SECTIONS { . = 0x0 .text : { *startup.o (.text) } .text.2 : { *(.tex*) } } I've wrote up a patch to fix this crash. Index: tools/lld/lib/ReaderWriter/LinkerScript.cpp <+>UTF-8 =================================================================== --- tools/lld/lib/ReaderWriter/LinkerScript.cpp (revision 8570c61c3fce7de2f655a20f8b184efa1bd97c00) +++ tools/lld/lib/ReaderWriter/LinkerScript.cpp (revision ) @@ -2557,7 +2557,7 @@ switch...

...Kledzik <kledzik at apple.com> wrote: > We need to be careful about what we mean by "frontend" and "backend" > of lld. Yeah, that terminology was really vague. I identify "frontend" with the driver (GNU ld, link.exe, ld64, etc) and "backend" with ReaderWriter (i.e. roughly the object file formats). > The Writer (backend?) actually gets a chance to contribute > atoms along with the Reader atoms which are fed to the Resolver. Could you elaborate on this? My understanding is that ReaderWriter is supposed to be basically a toolkit for emitting the o...

...n Windows with Cmake. > > Regards, > Andreas > > From 36855377f20b0492735339f36ed7c650a4c90624 Mon Sep 17 00:00:00 2001 > From: Andreas Wendleder <andreas.wendleder at gmail.com> > Date: Thu, 10 Jul 2014 10:58:32 +0100 > Subject: [PATCH] Remove LayoutPass dependency on ReaderWriter. > > It's not used anyway. > --- > include/lld/Passes/LayoutPass.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/include/lld/Passes/LayoutPass.h > b/include/lld/Passes/LayoutPass.h > index 3392480..ffb633d 100644 > --- a/include/lld/Passes/LayoutPass.h &...

...rtup.o (.text) } >> .text.2 : { *(.tex*) } >> } >> >> I've wrote up a patch to fix this crash. >> > > The patch looks good to me. > CC:ing Rafael and Michael as they wrote large part of the linker script support. > > >> Index: tools/lld/lib/ReaderWriter/LinkerScript.cpp >> <+>UTF-8 >> =================================================================== >> --- tools/lld/lib/ReaderWriter/LinkerScript.cpp (revision >> 8570c61c3fce7de2f655a20f8b184efa1bd97c00) >> +++ tools/lld/lib/ReaderWriter/LinkerScript.cpp...

...ommit ddca67a2b94f68985789fc8254fd1326e26269f6 Author: Andrew Kelley <superjoe30 at gmail.com> Date: Fri Dec 1 12:09:55 2017 -0500 LLD patch: workaround for buggy MACH-O code This reapplies 1a1414fc42c7beb25b6de4134d99884ea6544b57 to the embedded LLD. diff --git a/deps/lld/lib/ReaderWriter/MachO/ArchHandler_x86_64.cpp b/deps/lld/lib/ReaderWriter/MachO/ArchHandler_x86_64.cpp index d687ca5d..07958da4 100644 --- a/deps/lld/lib/ReaderWriter/MachO/ArchHandler_x86_64.cpp +++ b/deps/lld/lib/ReaderWriter/MachO/ArchHandler_x86_64.cpp @@ -617,7 +617,6 @@ void ArchHandler_x86_64::applyFixupFina...

On Jan 9, 2013, at 6:49 PM, Sean Silva wrote: >> The Writer (backend?) actually gets a chance to contribute >> atoms along with the Reader atoms which are fed to the Resolver. > > Could you elaborate on this? My understanding is that ReaderWriter is > supposed to be basically a toolkit for emitting the object files > ("mechanism"), while the different drivers use those APIs (along with > the Atom core linking model "mechanism") to emulate their respective > linkers (the "policy"). The reality is th...

...t;> Regards, >> Andreas >> >> From 36855377f20b0492735339f36ed7c650a4c90624 Mon Sep 17 00:00:00 2001 >> From: Andreas Wendleder <andreas.wendleder at gmail.com> >> Date: Thu, 10 Jul 2014 10:58:32 +0100 >> Subject: [PATCH] Remove LayoutPass dependency on ReaderWriter. >> >> It's not used anyway. >> --- >> include/lld/Passes/LayoutPass.h | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/include/lld/Passes/LayoutPass.h >> b/include/lld/Passes/LayoutPass.h >> index 3392480..ffb633d 100644 >>...

...9: 00000000 0 FILE LOCAL DEFAULT ABS test.c 10: 00000000 0 FILE LOCAL DEFAULT ABS ]] I suggest to remove assert from the RefNameBuilder::buildDuplicateNameMap() method. I think we do not break anything in that case. Any objections, comments, suggestions? [[ --- a/lib/ReaderWriter/YAML/ReaderWriterYAML.cpp +++ b/lib/ReaderWriter/YAML/ReaderWriterYAML.cpp @@ -101,7 +101,6 @@ public: } void buildDuplicateNameMap(const lld::Atom &atom) { - assert(!atom.name().empty()); NameToAtom::iterator pos = _nameMap.find(atom.name()); if (pos != _nameMap.end()) {...

...treamReader? If so how. The generic BitstreamReader class is public because it's used in other projects, including clang, to serialize data structures other than LLVM IR. The coding of the LLVM IR within the bitstream are private to the reader and writer modules. The functions exposed in ReaderWriter.h are the public interface to that functionality. > I tried to get a module out of a file that I'd read in to it using > this code: > > MemoryBuffer* memBuf = MemoryBuffer::getFile(filename, sizeof > filename, &errStr); > printf("errStr: %s\n", errStr.c_str(...