This is an automated email from Gerrit.
Tomas Vanek (van...@fbl.cz) just uploaded a new patch set to Gerrit, which you
can find at http://openocd.zylin.com/4080
-- gerrit
commit 0fda54b0d6f148c000df9a60755aca2bd7527008
Author: Tomas Vanek
Date: Thu Mar 23 10:13:09 2017 +0100
drivers/cms
> On 23 Mar 2017, at 18:50, Freddie Chopin wrote:
>
> ... However me and Liviu had a discussion about describing RTOS structure
> in a generic way and I'm still pretty certain that this is generally
> not possible in a generic and agnostic way. In the end it would become
> either extremely compl
Hi,
Am 21.03.2017 um 14:07 schrieb Mykhaylo Lyubun:
> 1) How long usually execute code review (this question from my manager)?
There is no definite answer to this question. It can take two weeks or
multiple months - having code and commit message in a well-structured,
easy-to-review way helps, as
On Thu, Mar 23, 2017 at 11:56 AM, Freddie Chopin
wrote:
> Yes, that would be another issue with implementing such RTOS support.
> It gets pretty hard when you have to modify both the RTOS and OpenOCD,
> while _NOT_ being the developer of that RTOS.
>
> I forgot about that, as I have the "luxury"
On Wed, 2017-03-22 at 18:51 +0100, Daniel Krebs wrote:
> Hi Freddie,
>
> first of all, I feel the same way as you do. I'm one of those guys
> who
> have undergone the endeavour to add RTOS support to OpenOCD (in my
> case
> RIOT OS). All the problems (slow OpenOCD release cycle, hard-coded
> offse
On Thu, 2017-03-23 at 10:23 +0100, Pierre-Marie de Rodat wrote:
> What makes you think that? My understanding of the design is that
> it's
> centered on adding new metadata sections to ELF binaries and make
> the
> debugger use this metedata. This looks quite embedded-friendly to me.
>
Maybe I
On Thu, Mar 23, 2017 at 11:40 AM, Freddie Chopin
wrote:
> On Thu, 2017-03-23 at 11:34 +, Yao Qi wrote:Providing
> > thread info isn't just printing thread name and state in "info
> > threads". GDB internally needs thread information too.
>
> But that's all GDB is getting from OpenOCD - threa
On Thu, 2017-03-23 at 10:50 +1300, Gareth McMullin wrote:
> I am also of the opinion that this would be better achieved as a
> Python extension to GDB.
> A while ago I worked on some Python scripts that fake it in GDB, by
> overriding the `thread`
> and `info threads` CLI commands.
> https://github
On Thu, 2017-03-23 at 11:34 +, Yao Qi wrote:Providing
> thread info isn't just printing thread name and state in "info
> threads". GDB internally needs thread information too.
But that's all GDB is getting from OpenOCD - thread name (string),
extra info (string) and stack frame (registers).
Hi all,
Could you answer on my questions:
1) How long usually execute code review (this question from my manager)?
2) Do I need do some extra steps to loaded my code into main repository and
generate msi or setup file (We want to send link on Open OCD to our customers)?
Best regards,
Misha
Th
Hi - I’ve been following this thread
A while ago - I proposed a very different architecture that would solve a lot
of this.
Fundamentally, there are two processes: (A) The GDB process and (B) the
GDBSERVER process.
When debugging an application that runs under a true OS (such as linux) this
Freddie Chopin writes:
>> Is it possible? Sure. But without looking at it in any real depth it
>> would be a major undertaking. GDB does not have the concept of
>> "Providers", it assembles state from many different sources: kernel,
>> glibc, libthread_db etc.
>
> Please note that for deeply embe
This is an automated email from Gerrit.
Jatin Muddu (jatin.mu...@gmail.com) just uploaded a new patch set to Gerrit,
which you can find at http://openocd.zylin.com/4079
-- gerrit
commit 78dd950c94965eebc6ed05f542cfdfc466e55c31
Author: jatinmuddu
Date: Wed Mar 22 15:04:23 2017 +0530
Addr
13 matches
Mail list logo
