Author: jingham
Date: Thu Jan 14 19:03:50 2016
New Revision: 257852
URL: http://llvm.org/viewvc/llvm-project?rev=257852&view=rev
Log:
The ASAN report fetching code had two latent bugs:
1) It was forward declaring functions without 'extern "C"'. That used to work
but only because of another bug
Author: amccarth
Date: Thu Jan 14 16:52:16 2016
New Revision: 257829
URL: http://llvm.org/viewvc/llvm-project?rev=257829&view=rev
Log:
Fix detection of teardown hooks that are already bound.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
Modified: lldb/trunk/packages/Python/
Author: spyffe
Date: Thu Jan 14 16:05:26 2016
New Revision: 257818
URL: http://llvm.org/viewvc/llvm-project?rev=257818&view=rev
Log:
Removed a redundant function call after review.
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Modified: lldb/trunk/source/Plugins/Sy
Author: spyffe
Date: Thu Jan 14 15:46:09 2016
New Revision: 257812
URL: http://llvm.org/viewvc/llvm-project?rev=257812&view=rev
Log:
Enable the use of modules in the expression parser by default.
If your program refers to modules (as indicated in DWARF) we will now try to
load these modules and g
Author: zturner
Date: Thu Jan 14 13:14:02 2016
New Revision: 257788
URL: http://llvm.org/viewvc/llvm-project?rev=257788&view=rev
Log:
Resubmit the fixes for TestProcessLaunch.py.
I was calling the base class tearDown() function the wrong way
which for some reason is ok on Python 3 but not on Pyth
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
In http://reviews.llvm.org/D16186#327081, @tberghammer wrote:
> I looked through the sections we have in a striped elf file and non of them
> have any information what would tell
Well, actually on Unix MOST things are files, it was Plan 9 in which that all
things are files, IIRC...
Jim
> On Jan 14, 2016, at 11:04 AM, Jim Ingham wrote:
>
> Yes, on unix all things are files and all files work the same except when
> they don't. I'd rather test the thing we ACTUALLY care
Yes, on unix all things are files and all files work the same except when they
don't. I'd rather test the thing we ACTUALLY care about, rather than testing
something else and assuming that it is going to work in the case we care about
as well.
Jim
> On Jan 14, 2016, at 10:58 AM, Zachary Turne
Author: spyffe
Date: Thu Jan 14 12:59:49 2016
New Revision: 257786
URL: http://llvm.org/viewvc/llvm-project?rev=257786&view=rev
Log:
Fixed a crasher when dealing with table entries that have blank names.
This can happen with -gmodules tables when an anonymous struct is referred to.
Modified:
Wouldn't testing with output redirecxted to a file still test that it is
being streamed as it is obtained rather than a big dump at the end? I mean
that's what stdout is right? Just a file. If you use a file on the
filesystem instead, just check the contents of the file after each
operation.
On
I worry giving up on testing using Python's stdout for the immediate output
stream. This is a very useful feature, allowing users to make Python based
commands that produce a bunch of output, and stream the output as it is being
gathered rather than having the command stall and then dump a bunc
tberghammer added a comment.
I looked through the sections we have in a striped elf file and non of them
have any information what would tell us the start address of the functions (it
isn't needed in runtime so it is removed to decrease the size).
Relocations won't really help because they will
How much time do you think it would take to determine whether or not using
the file-based approach would work? Because on the surface it sounds
fairly straightforward, and fixing it that way would allow us to not have
to xfail this on more platforms for reasons that we don't understand.
On Thu, J
The log just shows a timeout is happening in pexpect() - which I don’t have a
ready explanation for
X-failing for now is the proper recourse. But you might want to debug this at
some point, since it’s weird behavior. It looks like the command is not even
just silently erroring out - from the lo
clayborg added a comment.
It would be interesting to see if there are any relocations or any other hints
to help make correct function bounds from a stripped (.dynsym only) ELF file.
In MachO we have a LC_FUNCTION_STARTS load command (kind of like an ELF note)
that contains all start addresses
tberghammer added a comment.
Yes it will prevent the artificial size calculation for symbols with 0 size in
.dynsym. I think all function and data symbols should have a valid size so I am
not sure why we have this symbol size calculation in the first place but I
assume it is to work around some
clayborg added a comment.
We could just teach the standard decorators to detect the type of the "archs"
variable and do the right thing based off of the type. In the handler code you
could have:
retype = type(re.compile('hello, world'))
if isinstance(archs, list):
# Do what we do now
clayborg added a comment.
So does this mean any symbols whose byte size is zero will always have a byte
size of zero when parsed from a .dynsym section? What kinds of symbols have a
byte size of zero in the .dynsym? Seems like function symbols should always
have a valid byte size no? Why is the
zturner added a comment.
In http://reviews.llvm.org/D16049#326634, @labath wrote:
> In http://reviews.llvm.org/D16049#326631, @bhushan wrote:
>
> > Hi Zachary,
> >
> > If we use @skipIf then the list would require to contain all possible MIPS
> > variations and the list will grow long.
> > for
bhushan added a comment.
In http://reviews.llvm.org/D16049#326634, @labath wrote:
> In http://reviews.llvm.org/D16049#326631, @bhushan wrote:
>
> > Hi Zachary,
> >
> > If we use @skipIf then the list would require to contain all possible MIPS
> > variations and the list will grow long.
> > for
Author: aidandodds
Date: Thu Jan 14 09:39:28 2016
New Revision: 257772
URL: http://llvm.org/viewvc/llvm-project?rev=257772&view=rev
Log:
[RenderScript] Hook kernel invocation.
This patch adds a hook to track kernel invocations and to track all script and
allocation objects used.
Modified:
tberghammer created this revision.
tberghammer added a reviewer: clayborg.
tberghammer added a subscriber: lldb-commits.
Unconditionally accept symbol sizes from .dynsym
If an elf object file have no .symtab section then we create our symtab
representation based on the .dynsym section. The symtab
Author: tberghammer
Date: Thu Jan 14 06:49:48 2016
New Revision: 257761
URL: http://llvm.org/viewvc/llvm-project?rev=257761&view=rev
Log:
Update some XFAILs after the 3.8->3.9 version change
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_locations/T
This revision was automatically updated to reflect the committed changes.
Closed by commit rL257759: Fix ambiguous resolution of
clang::ArrayType/llvm::ArrayType in ClangAstContext (authored by EwanCrawford).
Changed prior to commit:
http://reviews.llvm.org/D16155?vs=44788&id=44854#toc
Reposit
Author: ewancrawford
Date: Thu Jan 14 06:18:09 2016
New Revision: 257759
URL: http://llvm.org/viewvc/llvm-project?rev=257759&view=rev
Log:
Fix ambiguous resolution of clang::ArrayType/llvm::ArrayType in ClangAstContext
Both llvm and clang have an ArrayType class, which can cause resolution to fai
I XFAIL-ed the test for Linux to get the build bot green again and filed a
bug at https://llvm.org/bugs/show_bug.cgi?id=26139
On Thu, Jan 14, 2016 at 2:18 AM Ying Chen via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Please see attached log file.
>
> Thanks,
> Ying
>
> On Wed, Jan 13, 201
Author: tberghammer
Date: Thu Jan 14 04:56:56 2016
New Revision: 257755
URL: http://llvm.org/viewvc/llvm-project?rev=257755&view=rev
Log:
XFAIL TestCommandScriptImmediateOutput on Linux
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCo
labath added a subscriber: labath.
labath added a comment.
In http://reviews.llvm.org/D16049#326631, @bhushan wrote:
> Hi Zachary,
>
> If we use @skipIf then the list would require to contain all possible MIPS
> variations and the list will grow long.
> for ex: @skipIf(archs=not_in(['mips32','m
bhushan updated the summary for this revision.
bhushan added a reviewer: zturner.
bhushan updated this revision to Diff 44841.
bhushan added a comment.
Hi Zachary,
If we use @skipIf then the list would require to contain all possible MIPS
variations and the list will grow long.
for ex: @skipIf(a
29 matches
Mail list logo
