labath added a comment.
Maybe we could start by splitting of the ObjectFile recognition code for the
debug_types section into a separate patch. That should be sufficiently
non-controversial and it would reduce the number of files touched by this patch
a bit.
https://reviews.llvm.org/D32167
labath added a comment.
One could probably concoct an example (using macros, token pasting and such)
where this would get it wrong, but that's probably not worth supporting.
Comment at: source/Expression/ExpressionSourceCode.cpp:193
+var_name == ConstString(".block_des
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Thanks. Please also update the `lit/Modules/elf-section-types.yaml` test to
include the new section type.
https://reviews.llvm.org/D46529
___
ll
labath added inline comments.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFDataExtractor.h:35-58
+ //--
+ /// Slide the data in the buffer so that access to the data will
+ /// start at offset \a offset.
+ //
labath created this revision.
labath added reviewers: clayborg, JDevlieghere.
Before this patch the two paths were doing very different things
- the apple path searched the .apple_names section, which contained mangled
names, as well as basenames of all functions. It returned any name it found.
labath created this revision.
labath added reviewers: jingham, clayborg.
Herald added a subscriber: mgorny.
The comments on this class were out of date with the implementation, and
the implementation itself was inconsistent with our usage of the Timeout
class (I started converting everything to us
labath closed this revision.
labath added a comment.
Herald added a subscriber: llvm-commits.
Looks like somebody already committed a patch like this.
Repository:
rL LLVM
https://reviews.llvm.org/D36977
___
lldb-commits mailing list
lldb-commits@
labath added inline comments.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp:905-908
ConstString demangled = mangled.GetDemangledName(cu_language);
if (demangled)
func_fullnames.Insert(demangled,
labath updated this revision to Diff 145717.
labath added a comment.
Stopped inserting demangled names into the fullname index and made the
FindFunctions index search in all three indices (fullname, basename, method).
The last two shouldn't really contain full names, but they seem to be required
f
labath added a comment.
In https://reviews.llvm.org/D46576#1091548, @clayborg wrote:
> Before adding the DWARF 5 index support, we should virtualize this searching
> and indexing into a base class. Then we make 1 class for manual DWARF
> indexing, one for Apple indexes, and one for DWARF5. Then
labath added a comment.
Looks great. Thanks.
Repository:
rL LLVM
https://reviews.llvm.org/D46529
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath added a comment.
This looks fine to me. I am not clicking accept yet, so other debug info folks
can take a look at this too.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:28
// Out of memory?
- if (cu_sp.get() == NULL)
+ if (!cu_sp)
return n
This revision was automatically updated to reflect the committed changes.
Closed by commit rL331855: [DWARF] Align non-accelerated function fullname
searching with the apple-tables… (authored by labath, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://review
labath added a comment.
Out of curiosity, are there any plans to improve the lldb-mi test reliability
situation? As it stands now, most of the lldb-mi tests are disabled one way or
another due to them being flaky.
Repository:
rL LLVM
https://reviews.llvm.org/D46588
__
This revision was automatically updated to reflect the committed changes.
Closed by commit rL331880: Modernize and clean-up the Predicate class (authored
by labath, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D46580?vs=145682&id=145
labath added a comment.
In https://reviews.llvm.org/D46588#1093054, @aprantl wrote:
> In https://reviews.llvm.org/D46588#1092884, @labath wrote:
>
> > Out of curiosity, are there any plans to improve the lldb-mi test
> > reliability situation? As it stands now, most of the lldb-mi tests are
> >
This revision was automatically updated to reflect the committed changes.
Closed by commit rL298058: Remove HostThreadLinux/Free/NetBSD (authored by
labath).
Changed prior to commit:
https://reviews.llvm.org/D30981?vs=91869&id=92115#toc
Repository:
rL LLVM
https://reviews.llvm.org/D30981
F
This revision was automatically updated to reflect the committed changes.
Closed by commit rL298066: Move GetAuxvData from Host to relevant process
plugins (authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D31031?vs=92000&id=92125#toc
Repository:
rL LLVM
https://review
labath created this revision.
ofstream does not handle paths with non-ascii characters correctly on
windows, so I am switching these to llvm streams to fix that.
Ideally I'd like to replace the two occurences of ifstream as well, but
it's not clear to me what is the right replacement, as llvm int
labath added a comment.
In https://reviews.llvm.org/D31079#703911, @zturner wrote:
> In the places where you want to read from an `ifstream` and write to a
> socket, you might consider using `llvm::sys::fs::copy_file`, declared in
> `Support/FileSystem.h`. Currently it takes two paths, but all
labath added a comment.
I think you missed one occurence in ModuleCache.cpp. This one creates a full
directory structure, so you will probably need recursion there (unlike in the
rest of these cases, which seem fine). Also unlike the rest of these cases,
that one is actually covered by a unit t
labath added a reviewer: jingham.
labath added inline comments.
Comment at:
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp:813
+ auto perms =
+ static_cast(packet.GetHexMaxU32(false,
UINT32_MAX));
if (packet.GetChar() == ',') {
--
labath added a comment.
In https://reviews.llvm.org/D31086#704122, @zturner wrote:
> That one is calling a file static function `MakeDirectory`, not
> `FileSystem::MakeDirectory`, and the implementation of that function already
> calls `llvm::sys::fs::create_directories()` to create the whole t
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Cool. Nevermind me then.
https://reviews.llvm.org/D31089
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/
labath added a comment.
Looks like a great start. If you want to continue and get live process
debugging working as well, you should definitely sync up with kamil (i.e. don't
start from ProcessFreeBSD, his process plugin should be a much better starting
point).
In terms of this patch, I have a
labath accepted this revision.
labath added a comment.
cool
https://reviews.llvm.org/D31108
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
cool
https://reviews.llvm.org/D3
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lld
labath added a comment.
In https://reviews.llvm.org/D31086#704518, @sas wrote:
> The second behavioral change seems good but the first thing you described is
> a bit odd. Creating folders with 770 does not seem like a common behavior,
> and 700 or 755 is usually more standard.
Don't forget th
labath added inline comments.
Comment at: lldb/include/lldb/Utility/TildeExpressionResolver.h:62
+
+class MockTildeExpressionResolver : public TildeExpressionResolver {
+ llvm::StringRef CurrentUser;
I find it very strange to see the Mock object in a regular hea
labath added a comment.
I like the idea of adding boilerplate first, so that we can than better focus
on the important stuff later. However, I think you've have gone a bit too far
with it -- you introduce a lot of functions I am pretty sure will not be
necessary for your case, or that should be
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
At one point we will need to come up with a better way to control these
features.
Repository:
rL LLVM
https://reviews.llvm.org/D31146
___
lld
labath added a comment.
In https://reviews.llvm.org/D31129#705597, @zturner wrote:
> See what you think about this. I've created a folder called `Mocks` under
> `Utility`, and created a new target out of it. `UtilityTests` links against
> it, and so does `InterpreterTests`. To do this I had
labath added a comment.
In https://reviews.llvm.org/D31146#706249, @krytarowski wrote:
> I'm still evaluating whether to implement on the kernel side
> `PT_SET_SIGPASS`/`PT_GET_SIGPASS`. Some software like floating point can use
> it heavily.
Also there are programs which use SIGALRM or realt
This revision was automatically updated to reflect the committed changes.
Closed by commit rL298375: Replace std::ofstream with llvm::raw_fd_ostream
(authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D31079?vs=92144&id=92484#toc
Repository:
rL LLVM
https://reviews.llvm.
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Heh... I did not expect it would get this small, but ok. :)
Repository:
rL LLVM
https://reviews.llvm.org/D31138
___
lldb-commits mailing list
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
I think you should group these "add netbsd to a list" type of changes into
single diff. There's not point in reviewing each separately.
Repository:
rL LLVM
https://reviews.llvm.org/D31192
labath added inline comments.
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:675
+ llvm::Triple host_triple(llvm::sys::getDefaultTargetTriple());
+ target_arch.GetTriple().setOS(host_triple.getOS());
+}
I'm not terribly happy with th
labath added a comment.
BTW, thank you for adding the test. It's not obvious from the patch: how big
are the core files?
Repository:
rL LLVM
https://reviews.llvm.org/D31280
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.l
labath added inline comments.
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:675
+ llvm::Triple host_triple(llvm::sys::getDefaultTargetTriple());
+ target_arch.GetTriple().setOS(host_triple.getOS());
+}
nitesh.jain wrote:
> labath wr
labath added inline comments.
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:675
+ llvm::Triple host_triple(llvm::sys::getDefaultTargetTriple());
+ target_arch.GetTriple().setOS(host_triple.getOS());
+}
nitesh.jain wrote:
> labath wr
labath added a comment.
Thank you for that.
I just have one more concern. I see two places where you are copying the
archspec from core file to the target and then back again. I must be missing
something, because that looks completely unnecessary at first sight. What is
the reason behind that?
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Ah, that explains it, thanks.
Let's give Greg a chance to comment, but otherwise I am fine with this.
https://reviews.llvm.org/D31280
___
lldb-c
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Thank you.
https://reviews.llvm.org/D30457
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listin
labath added a comment.
Does anyone object to me landing this? I am going to be careful and wait for
the change to trickle through CI before submitting any followup changes.
https://reviews.llvm.org/D30984
___
lldb-commits mailing list
lldb-commits
labath added a comment.
This doesn't bother me too much, but i'm curious about how are you getting
anything reasonable out of the test suite without a working compiler (?)
https://reviews.llvm.org/D31335
___
lldb-commits mailing list
lldb-commits@l
labath added inline comments.
Comment at: source/CMakeLists.txt:25
+include_directories(
+ Plugins/Process/POSIX
+ )
krytarowski wrote:
> @labath are the includes for Plugins/Process/FreeBSD and
> Plugins/Process/FreeBSD necessary? I don't need to add Plugins/
labath added a comment.
I am afraid I will be away for two weeks as well.. :(
The FileLogCallback thingy seems a bit unfortunate, but I don't see anything
too controversial based on a quick scan..
https://reviews.llvm.org/D31357
___
lldb-commits m
labath added a comment.
I wasn't able to go into this too deeply, but here is what I have after a quick
pass. I won't be able to review this thoroughly that soon, but I think it can
go in after you take my comments into consideration.
Comment at: source/Plugins/Process/NetBSD
labath added inline comments.
Comment at: source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp:249
+ // Initialize new thread
+ struct ptrace_lwpinfo info = {};
+ Error error = PtraceWrapper(PT_LWPINFO, pid, &info, sizeof(info));
This is the third
labath added inline comments.
Comment at: source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp:249
+ // Initialize new thread
+ struct ptrace_lwpinfo info = {};
+ Error error = PtraceWrapper(PT_LWPINFO, pid, &info, sizeof(info));
krytarowski wrote
labath added a comment.
We don't depend on the RuntimeDyld component of llvm directy -- we only use it
indirectly through the ExecutionEngine component. Shouldn't that be reflected
as a dependency in the build system somehow, so that the former can be pulled
in directly ?
RuntimeDyld is listed
labath added a comment.
In https://reviews.llvm.org/D30984#711806, @EricWF wrote:
> I don't see anything wrong with this, but I only know libc++ and not LLDB.
I'm not sure why you ended up here. I think you have too wide phabricator
filter somewhere. :)
>
>
>> libc++'s atomic does not pla
This revision was automatically updated to reflect the committed changes.
Closed by commit rL299028: Centralize libc++ test skipping logic (authored by
labath).
Changed prior to commit:
https://reviews.llvm.org/D30984?vs=91878&id=93407#toc
Repository:
rL LLVM
https://reviews.llvm.org/D30984
labath added a comment.
The additional check sounds fine. There's a test for this class in
unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp where you can
add a test for this behavior.
https://reviews.llvm.org/D31485
___
lldb-commi
labath added a comment.
I cant help but feel that this could have been done in a simpler way, but then
again, some of the cases you have dug up are quite tricky.
I think we should do some performance measurements to see whether this needs
more optimising or it's fine as is.
I propose the follo
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Thank you. Keep up the good work.
Repository:
rL LLVM
https://reviews.llvm.org/D31450
___
lldb-commits mailing list
lldb-commits@lists.llvm.or
labath accepted this revision.
labath added a comment.
Thank you for adding the test. Lgtm, assuming the second getmemoryregioninfo
call is accidental.
Comment at:
unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp:373
+
+ result = std::async(std::launch::asyn
labath added a comment.
In https://reviews.llvm.org/D31451#714850, @eugene wrote:
> I did some micro-benchmarking and on average new parser is ~3 time slower
> than the old one. (new parser - ~200k string/s, old parser - ~700k string/s)
> clang::Lexer appears to be the slowest part of it.
>
>
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Thank you
In https://reviews.llvm.org/D31451#715664, @eugene wrote:
> In https://reviews.llvm.org/D31451#715649, @tberghammer wrote:
>
> > Because of this I think some targeted micro benchmark
labath created this revision.
Herald added a subscriber: mgorny.
The files there can always be referred to using their full path, which
is what most of the code has been doing already, so this makes the
situation more consistent. Also fix the the code in the FreeBSD plugin
to use the new paths.
labath created this revision.
Herald added a reviewer: EricWF.
The iteration list through the available data formatters was undefined,
which meant that the vector formatter kicked in only in cases
where it happened to be queried before the general vector formatter. To
fix this, I merge the two dat
labath updated this revision to Diff 94667.
labath added a comment.
Remove the vector summary provider as well (picked up from Tamas's
version of the patch).
https://reviews.llvm.org/D31880
Files:
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vbool/
labath requested changes to this revision.
labath added a comment.
This revision now requires changes to proceed.
This makes all sorts of tests fail. Regardless of your platform you should at
least be able to reproduce the following failures:
FAIL: test_FPR_SSE (functionalities/postmortem/elf-
labath added a comment.
When I created the `MainLoop` class, i was hoping it would become the central
place for all select-like functionality. Currently it uses pselect, but i don't
see a reason we couldn't switch it to ppoll (but we actually don't have to, as
the current implementation should
This revision was automatically updated to reflect the committed changes.
Closed by commit rL299933: Remove Plugins/Process/POSIX from
include_directories (authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D31877?vs=94656&id=94805#toc
Repository:
rL LLVM
https://reviews
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
This is fine, as far as i am concerned.
Comment at: tools/debugserver/source/CMakeLists.txt:117
+POST_BUILD
+# Note: --entitlements option removed (see comment above)
labath marked 3 inline comments as done.
labath added inline comments.
Comment at: source/Plugins/Language/CPlusPlus/LibCxxVector.cpp:301-304
+ TypeImpl type = valobj_sp->GetTypeImpl();
+ if (!type.IsValid())
+return nullptr;
+ CompilerType compiler_type = type.GetCompiler
labath updated this revision to Diff 94807.
labath added a comment.
Address review comments.
https://reviews.llvm.org/D31880
Files:
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vbool/TestDataFormatterLibcxxVBool.py
source/Plugins/Language/CPlusPlu
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Thank you very much. I am soo happy that these files are going away.
In https://reviews.llvm.org/D31969#724508, @zturner wrote:
> How much would it complicate things to move the hand maintaine
labath added a comment.
In https://reviews.llvm.org/D31823#724334, @beanz wrote:
> @labath, I could adapt this into the `MainLoop` class, but I would actually
> want to change how that class hierarchy is implemented. Regardless of the
> event handling/polling model you use much of the code is i
This revision was automatically updated to reflect the committed changes.
Closed by commit rL300047: Fix libc++ vector data formatter (bug #32553)
(authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D31880?vs=94807&id=94951#toc
Repository:
rL LLVM
https://reviews.llvm.or
labath created this revision.
When a call instruction is the last instruction in a function, the
backtrace PC will point past the end of the function. We already had
special code to handle that, but we did not handle the case where the PC
ends up outside of the bounds of the module containing the
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
looks good, thank you.
https://reviews.llvm.org/D32087
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/ma
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Thank you for taking the time to do this.
It looks like ppoll was added to linux quite a long time ago, but we still get
some patches supporting surprisingly old kernels. I hope it doesn't com
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
lgtm
Comment at:
source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp:22
+// clang-format off
+#include
It is enough to place an empty li
labath added a comment.
I am confused. `m_registers_count` is declared as `uint8_t` at
`RegisterContextPOSIX_mips64.h:67`...
https://reviews.llvm.org/D32137
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mai
labath added a comment.
The new tests which are not passing need to be disabled -- we cannot have a
red tree while this is being developed.
https://reviews.llvm.org/D32167
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm
labath added a comment.
In https://reviews.llvm.org/D32167#729508, @clayborg wrote:
> Yeah, I was having trouble getting a real read on what was failing due to a
> non Ubuntu setup at work for me. Is there any way to run a patch on one of
> the buildbots? If not, can you email me the list of wh
labath added a comment.
It looks like you had a fun day yesterday. :) Unfortunately, I have to add to
your problems, as I've had to revert your commit due to a fairly big problem.
The problem that it can happen that the create-a-bunch-of-listening-sockets
loop can sometimes only create an ipv6
labath requested changes to this revision.
labath added a comment.
This revision now requires changes to proceed.
This is the list I am getting when using ToT clang targetting x86_64 linux.
Note that there are a couple of non-type-units test broken by this. This needs
to be addressed first.
=
labath created this revision.
MergeFrom was updating the architecture if the target triple did not
have it set. However, it was leaving the core field as invalid. This
resulted in assertion failures in core file tests as a missing core
meant we were unable to compute the address byte size properly
labath updated this revision to Diff 95722.
labath added a comment.
Also remove the skipIfDarwin decorators, as they should work now -- there was
nothing darwin-specific about them, just our bots don't run assert builds at the
moment.
https://reviews.llvm.org/D32221
Files:
include/lldb/Core/A
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
lgtm. You might consider using llvm::formatv instead of the raw snprintf -- it
would make the `PRIx64` macros more readable.
https://reviews.llvm.org/D32184
___
labath added a comment.
Thanks for digging into this, I've learned something new today. Fixing this
with a cast seems reasonable then.
https://reviews.llvm.org/D32137
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/c
labath added a comment.
A test would infinitely times more valuable then a demo script. What is the
tiniest core file you can produce on NetBSD? (on linux we've gotten them down
to about 20K) Then we could check that in and write a test for it...
Repository:
rL LLVM
https://reviews.llvm.org
This revision was automatically updated to reflect the committed changes.
Closed by commit rL300836: Recompute ArchSpec core after MergeFrom (authored by
labath).
Changed prior to commit:
https://reviews.llvm.org/D32221?vs=95722&id=95941#toc
Repository:
rL LLVM
https://reviews.llvm.org/D322
labath added a comment.
In https://reviews.llvm.org/D32149#731920, @krytarowski wrote:
> In https://reviews.llvm.org/D32149#731887, @labath wrote:
>
> > A test would infinitely times more valuable then a demo script. What is the
> > tiniest core file you can produce on NetBSD? (on linux we've go
labath added a comment.
Jim, Jason, could one of you take a look at this please?
This part of the code is not really my specialty, so I'd appreciate your
thoughts on this.
https://reviews.llvm.org/D32022
___
lldb-commits mailing list
lldb-commits@
labath created this revision.
Herald added a subscriber: aprantl.
Since r299449 "Make RuntimeDyld honor the ProcessAllSections flag." we
have been experiencing an assertion failure when evaluating expressions
on linux.
Based on my investigation, the sequence of events is as follows:
- lldb sets
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Looks good, thank you.
Out of curiosity, have you observed any performance improvements resulting from
this?
Repository:
rL LLVM
https://reviews.llvm.org/D32306
___
labath added a comment.
Thank you for looking at this. My response is below.
In https://reviews.llvm.org/D32022#733223, @jasonmolenda wrote:
> Hi Pavel, I'd document the new flag in include/lldb/Core/Address.h where we
> have documentation for the other flags being used.
>
> It seems like we're
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
sounds reasonable
https://reviews.llvm.org/D32340
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman
labath created this revision.
the reason for this is two-fold:
- getaddrinfo without the extra arguments will return the same
(network-level) address multiple times, once for each supported
transport protocol, which is not what is usually intended (it certainly
wasn't in https://reviews.llvm.org
This revision was automatically updated to reflect the committed changes.
Closed by commit rL301168: Add more arguments to SocketAddress::GetAddressInfo
(authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D32357?vs=96160&id=96363#toc
Repository:
rL LLVM
https://reviews.l
labath added a comment.
Thanks for the patch. Could you please also add an appropriate test for it?
Doing something similar to what
`packages/Python/lldbsuite/test/functionalities/frame_var/TestFrameVar.py` does
should be the easiest way to test this.
Repository:
rL LLVM
https://reviews.ll
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
labath created this revision.
Herald added subscribers: mgorny, srhines.
The toolchain file has been deprecated in favor of the "official"
toolchain file present in the Android NDK. Also update the web
build instructions to reflect this.
https://reviews.llvm.org/D32441
Files:
cmake/platforms/
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
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
labath marked 2 inline comments as done.
labath added inline comments.
Comment at: www/build.html:488-493
+
-DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK_HOME/build/cmake/android.toolchain.cmake
\
+ -DANDROID_ABI=arm64-v8a \
+ -DANDROID_PLATFORM=and
1001 - 1100 of 6408 matches
Mail list logo
