Re: [lldb-dev] [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum version to 3.4.3

[Zachary Turner via lldb-dev]

Windows LLDB is done

On Thu, May 26, 2016 at 2:39 AM Daniel Sanders via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> All the MIPS buildbots are ready too.
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] *On Behalf Of 
> *NAKAMURA
> Takumi via llvm-dev
> *Sent:* 25 May 2016 23:03
> *To:* Chris Bieneman; llvm-...@lists.llvm.org; cfe-...@lists.llvm.org;
> lldb-dev@lists.llvm.org
> *Subject:* Re: [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum
> version to 3.4.3
>
>
>
> I am ready, regarding to, http://bb.pgr.jp/
>
> On Wed, May 25, 2016 at 5:54 AM Chris Bieneman  wrote:
>
> Meant to send this yesterday, but I want to remind everyone that we’re
> going to be raising the CMake minimum version to 3.4.3 next week.
>
> If you maintain bots please ensure that your bots are updated by end of
> day 5/29 so that we can move on 5/30 (next Monday).
>
> I have already heard from most bot owners either saying they had made the
> change, or scheduled to make it.
>
> If you have any questions or concerns please let me know.
>
> Thank you,
> -Chris
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Ubuntu buildbot timing after -gmodules

[Pavel Labath via lldb-dev]

That's good news. We probably have some reserves left in there due to
the scheduling of tests of different size.

On 26 May 2016 at 16:30, Todd Fiala  wrote:
> Hi Pavel,
>
> FYI -
>
> I took a look at the ubuntu 14.04 x86_64 cmake buildbot before and after the
> -gmodules change landed, and it looks like the total runtime is up about
> 12%.  (Now ~28 minutes, before ~25 minutes).
>
> Doesn't seem too bad for the scope of increased coverage.
>
> --
> -Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Ubuntu buildbot timing after -gmodules

[Todd Fiala via lldb-dev]

Hi Pavel,

FYI -

I took a look at the ubuntu 14.04 x86_64 cmake buildbot before and after
the -gmodules change landed, and it looks like the total runtime is up
about 12%.  (Now ~28 minutes, before ~25 minutes).

Doesn't seem too bad for the scope of increased coverage.

-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum version to 3.4.3

[Daniel Sanders via lldb-dev]

All the MIPS buildbots are ready too.

From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of NAKAMURA 
Takumi via llvm-dev
Sent: 25 May 2016 23:03
To: Chris Bieneman; llvm-...@lists.llvm.org; cfe-...@lists.llvm.org; 
lldb-dev@lists.llvm.org
Subject: Re: [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum version to 
3.4.3

I am ready, regarding to, http://bb.pgr.jp/
On Wed, May 25, 2016 at 5:54 AM Chris Bieneman 
> wrote:
Meant to send this yesterday, but I want to remind everyone that we’re going to 
be raising the CMake minimum version to 3.4.3 next week.

If you maintain bots please ensure that your bots are updated by end of day 
5/29 so that we can move on 5/30 (next Monday).

I have already heard from most bot owners either saying they had made the 
change, or scheduled to make it.

If you have any questions or concerns please let me know.

Thank you,
-Chris
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Discrete code and data memories

[Tyro Software via lldb-dev]

Thanks hugely for those very useful pointers (groan...)

It seems that embedding address space info in the high-order bits of the
common address is the common hack around the problem and likely to remain
so in the near term (at least I didn't see anything in the mail threads
suggesting an implementation suitable for merging back, or even a plan for
this).

I did see a reference to better support in GDB: "Embecosm has made
significant contributions to GDB, particularly in supporting Harvard
architectures with multiple address spaces" but when briefly reading the
GDB current docs and release notes didn't find any description of extended
addressing. Perhaps you know what the GDB support amounts to?

Thanks once again
/Tyro

On Thu, May 26, 2016 at 12:20 AM, Ted Woodward 
wrote:

> What Tyro is describing is called a "Harvard architecture" -
> https://en.wikipedia.org/wiki/Harvard_architecture . It contrasts with
> the von Neumann architecture used by most machines today.
>
> Hexagon has a unified memory map, but I've worked with other DSPs
> (Motorola DSP56xxx) that have a code bus and 1 or more data busses. 56300
> was 24 bit, and called them p, x and y memories. 56600 had 24 bit p memory
> and 16 bit x memory. And my product at my previous employer took this idea
> of memory spaces a bit farther, and we could use different spaces to access
> the same memory in different ways. So a debugger attached to a Freescale
> T4240 processor could access an address as physical through the SoC,
> physical/virtual through the e6500 PowerPC core (really 1:1 mapping for
> "physical"), cacheable/non cacheable, code/data (code applies the
> self-modifying code sequence, used primarily for software breakpoints). We
> could combine these options in appropriate ways. The memory access
> functions took a memory space, address, size and count.
>
> To implement this in LLDB, we'd need to have a way to decorate a memory
> range with interesting attributes, and a way to get this info over to the
> remote gdb-server.
>
> Duane Ellis talks about some of the issues with supporting this on the GDB
> mailing list: http://comments.gmane.org/gmane.comp.gdb.devel/36147
>
> This actually came up here 2 years ago -
> http://lists.llvm.org/pipermail/lldb-dev/2014-May/004081.html .
>
> Ted
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg
> Clayton via lldb-dev
> Sent: Wednesday, May 25, 2016 3:57 PM
> To: Tyro Software 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Discrete code and data memories
>
> I believe that some of the DSPs we have support for (Hexagon?) has this
> kind of issue. I would speak to Ted Woodward and see if they do anything
> special for this.
>
> Greg Clayton
>
> > On May 25, 2016, at 2:16 AM, Tyro Software via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > I'm trying to implement LLDB support for an architecture where code and
> data stores can be explicitly separated and can even have overlapping
> addresses (one can think of it as ROM and RAM, with separate access buses).
> >
> > My impression is that LLDB somewhat presumes a hybrid memory map, e.g.
> the client requests "qMemoryRegionInfo:$PC" for the program counter value
> but might also do "qMemoryRegionInfo:$SP" for the stack pointer and from
> the address value alone one can't safely determine which memory type is
> meant. A similar issue would exist for the X/x commands.
> >
> > I apologise for not knowing better terminology to describe this - quite
> possibly LLDB does cater for it and I haven't understood the description,
> e.g. there's some way to "adorn" an address or set some context or scope
> for it through a preceding command?
> >
> > Thanks
> > /Tyro
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev