No idea, the checkout just timed out. I tried to play with sparse
checkouts, etc. and my current hypothesis that the large number of
revisions makes it unhappy.
On Fri, Nov 9, 2018 at 2:39 AM James Y Knight wrote:
>
> It'd be nice to know what about our repository is breaking it. Do they have
> a
It'd be nice to know what about our repository is breaking it. Do they have
any idea what that is?
For example -- I think that we probably will want to archive+discard many
of the random branches and tags currently in the repository. If the large
number of branches and tags is breaking it, then ma
Thanks guys! Adding the plugin did the trick.
Adrian
> On Nov 8, 2018, at 1:01 PM, ted.woodw...@codeaurora.org wrote:
>
> You're probably going to want to use the Static DYLD plugin.
>
> --
> Ted Woodward
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code A
Some status update wrt GitHub SVN bridge.
It does not work for any non-trivial (= LLVM) repo. I filled the issue
there, however, there is no ETA when it will be fixed. Even worse,
there are no promises that the issue will be addressed at all. Though
they are aware that this is the issue for us.
On
Zachary Turner via llvm-dev writes:
> Just so I'm clear, are we going to attempt to clean up and/or merge
> the components? If we are, it makes sense to do that before we start
> putting ourselves as default CC's on the various components since they
> will just change. If not, it would be nice to
You're probably going to want to use the Static DYLD plugin.
--
Ted Woodward
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
-Original Message-
From: jing...@apple.com
Sent: Thursday, November 8
Just so I'm clear, are we going to attempt to clean up and/or merge the
components? If we are, it makes sense to do that before we start putting
ourselves as default CC's on the various components since they will just
change. If not, it would be nice to get some clarification on that now.
I've p
> On Nov 8, 2018, at 11:18 AM, Adrian Harris wrote:
>
> Thanks Jim - that makes sense for the types of targets that lldb interacts
> with mostly.
>
> In my particular case, nothing is getting 'launched' - rather I'm attaching
> to an already running target. The elf that I'm pointing to is an
Thanks Jim - that makes sense for the types of targets that lldb interacts with
mostly.
In my particular case, nothing is getting 'launched' - rather I'm attaching to
an already running target. The elf that I'm pointing to is an exact executable
image as the target has no OS to speak of and is
lldb finds the symbol you asked for in the elf file's symbols, and makes a
"location" for that address in that binary (as a section-relative address).
But that won't help it actually SET the breakpoint, since that doesn't tell us
where that section will end up in the executable image when it ru
(lldb) file tile.elf
Current executable set to 'tile.elf' (cs).
(lldb) b main
lldb Target::AddBreakpoint (internal = no) => break_id = 1: name =
'main'
lldb Added location: 1.1:
module = tile.elf
compile unit = token_pass.c
function = main
location = token_pass.c
What happens if you do this:
(lldb) file tile.elf
(lldb) b main
(lldb) gdb-remote
?
--
Ted Woodward
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
-Original Message-
From: lldb-dev On Behalf
Hi Everyone,
I'm unable to resolve *symbolic* breakpoints on a gdb-remote target. Address
breakpoints work fine. I suspect this is probably some form of user-error, but
I've had no luck figuring it out on my own.
My target has llvm support and lldb has been patched to add a new target as
well.
Hi,
Yesterday, I’ve landed a description for how reported bugs should be flowing
through the various stages of a bug’s life (triage, fixing, closing, …) at
http://llvm.org/docs/BugLifeCycle.html.
Thanks for the many many people who provided ideas and feedback for this!
With there now being a de
What's the status here?
Can someone keep https://llvm.org/docs/Proposals/GitHubMove.html updated
with the current status of things?
And once things are usable, probably update
https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
as well.
On Wed, Oct 24, 2018 at 4:
15 matches
Mail list logo
