This revision was automatically updated to reflect the committed changes.
Closed by commit rL301917: ObjectFileELF: Fix symbol lookup in bss section
(authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D32434?vs=96541&id=97435#toc
Repository:
rL LLVM
https://reviews.llvm.
zturner accepted this revision.
zturner added a comment.
Alright, thanks for trying anyway!
https://reviews.llvm.org/D32434
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath requested review of this revision.
labath added a comment.
This revision is now accepted and ready to land.
In https://reviews.llvm.org/D32434#737205, @labath wrote:
> In https://reviews.llvm.org/D32434#737179, @zturner wrote:
>
> > If you look at the source code of yaml2obj, all this boil
labath planned changes to this revision.
labath added a comment.
In https://reviews.llvm.org/D32434#737179, @zturner wrote:
> If you look at the source code of yaml2obj, all this boils down to a single
> call to `ELFState::writeELF`. If you just link against that, we could
> avoid even shellin
zturner added a comment.
If you look at the source code of yaml2obj, all this boils down to a single
call to `ELFState::writeELF`. If you just link against that, we could avoid
even shelling out to an external tool, and the YAML could be a string literal
defined inside the unit test cpp file.
eugene accepted this revision.
eugene added a comment.
This revision is now accepted and ready to land.
Neatly done!
https://reviews.llvm.org/D32434
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/list
labath added a reviewer: beanz.
labath added a subscriber: beanz.
labath added a comment.
Ok, wiring yaml2obj up was easier than I expected (for cmake, we'll still need
to figure out what to do with the xcode build). Let me know what you make of
this.
Also adding @beanz, in case he has any thou
labath updated this revision to Diff 96541.
labath added a comment.
Use yaml2obj to avoid checking in a binary.
https://reviews.llvm.org/D32434
Files:
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
unittests/ObjectFile/ELF/CMakeLists.txt
unittests/ObjectFile/ELF/Inputs/sections-resolve-c
labath updated this revision to Diff 96540.
labath added a comment.
Use yaml2obj to avoid checking in a binary.
https://reviews.llvm.org/D32434
Files:
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
unittests/ObjectFile/ELF/CMakeLists.txt
unittests/ObjectFile/ELF/Inputs/sections-resolve-c
On 24 April 2017 at 23:16, Zachary Turner wrote:
> I suppose that's a reasonable concern. I also didn't notice that this was
> a unittest, I assumed it was a lit test.
>
> If that's the case, is there any way to use llvm/Object to construct a
> minimal ELF file in memory with a hardcoded symbol
I suppose that's a reasonable concern. I also didn't notice that this was
a unittest, I assumed it was a lit test.
If that's the case, is there any way to use llvm/Object to construct a
minimal ELF file in memory with a hardcoded symbol in the BSS section. It
can even be missing certain critical
labath added a comment.
> We don't support running the test suite on Windows with MSVC. We run it
> with clang targeting windows instead. So anyone running the test suite on
> Windows is already using clang, and we can just specify a linux triple to
> get an ELF binary.
You'll need a linker
We don't support running the test suite on Windows with MSVC. We run it
with clang targeting windows instead. So anyone running the test suite on
Windows is already using clang, and we can just specify a linux triple to
get an ELF binary.
On Mon, Apr 24, 2017 at 2:47 PM Eugene Zemtsov wrote:
>
Microsoft Visual C++ first comes to my mind.
On Mon, Apr 24, 2017 at 2:31 PM, Zachary Turner wrote:
> Which C compilers do we have that are not capable of producing ELF
> binaries? GCC on Windows maybe? That's not even a supported test
> configuration.
>
> On Mon, Apr 24, 2017 at 2:29 PM Pave
Which C compilers do we have that are not capable of producing ELF
binaries? GCC on Windows maybe? That's not even a supported test
configuration.
On Mon, Apr 24, 2017 at 2:29 PM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> In https://reviews.ll
labath added a comment.
In https://reviews.llvm.org/D32434#735877, @eugene wrote:
> Is it really necessary to check in binary ELF files?
> I understand that we don't always have a C compiler capable of producing ELF
> files, but maybe it's ok to skip this test on those platforms.
That is so
eugene added a comment.
Is it really necessary to check in binary ELF files?
I understand that we don't always have a C compiler capable of producing ELF
files, but maybe it's ok to skip this test on those platforms.
https://reviews.llvm.org/D32434
_
labath created this revision.
Herald added a subscriber: mgorny.
If we have symbol information in a separate file, we need to be very
careful about presenting a unified section view of module to the rest of
the debugger. ObjectFileELF had code to handle that, but it was being
overly cautious -- th
18 matches
Mail list logo
