Re: [PATCH v2] covoar: Store address-to-line info outside of DWARF

2021-06-02 Thread Chris Johns
Looking good with a single comment below ... On 3/6/21 6:08 am, Alex White wrote: > This adds the AddressToLineMapper class and supporting classes to > assume responsibility of tracking address-to-line information. > > This allows the DWARF library to properly cleanup all of its resources > and l

Re: Selection of ethernet peripheral by application

2021-06-02 Thread Chris Johns
On 3/6/21 4:37 am, Kinsey Moore wrote: > Hello, > > From what I’ve seen of the various BSPs supported by LibBSD that have multiple > ethernet peripherals, > > only one tends to be chosen and supported. I’ve encountered a situation where > the majority of platform > > examples (Zynq Ultrascale+ M

[PATCH v2] covoar: Store address-to-line info outside of DWARF

2021-06-02 Thread Alex White
This adds the AddressToLineMapper class and supporting classes to assume responsibility of tracking address-to-line information. This allows the DWARF library to properly cleanup all of its resources and leads to significant memory savings. Closes #4383 --- rtemstoolkit/rld-dwarf.cpp |

Re: Selection of ethernet peripheral by application

2021-06-02 Thread Joel Sherrill
On Wed, Jun 2, 2021 at 1:37 PM Kinsey Moore wrote: > Hello, > > From what I’ve seen of the various BSPs supported by LibBSD that have > multiple ethernet peripherals, > > only one tends to be chosen and supported. I’ve encountered a situation > where the majority of platform > > examples (Zynq Ul

Selection of ethernet peripheral by application

2021-06-02 Thread Kinsey Moore
Hello, >From what I've seen of the various BSPs supported by LibBSD that have multiple >ethernet peripherals, only one tends to be chosen and supported. I've encountered a situation where the majority of platform examples (Zynq Ultrascale+ MPSoC dev boards) use CGEM3 as the only/primary ethernet

Re: [PATCH rtems-docs] eng/vc-authors: Add section on migrating personal repo to top-level

2021-06-02 Thread Vijay Kumar Banerjee
On Wed, Jun 2, 2021 at 9:21 AM Gedare Bloom wrote: > > looks ok > Thanks. Pushed! > On Sun, May 30, 2021 at 3:12 PM Vijay Kumar Banerjee wrote: > > > > --- > > eng/vc-authors.rst | 46 ++ > > 1 file changed, 46 insertions(+) > > > > diff --git a/eng/vc

Re: [PATCH] cpukit/libdebugger: Fix for sockaddr_in not being initialized

2021-06-02 Thread Vijay Kumar Banerjee
On Tue, Jun 1, 2021 at 12:20 PM Joel Sherrill wrote: > > This looks like it should fix the issue. > > OK to push. > Pushed. Thanks. > On Tue, Jun 1, 2021 at 1:06 PM Harrison Edward Gerber > wrote: >> >> From: Harrison Edward Gerber >> >> See also CID 1468684 >> >> Closes #4445 >> --- >> cpuki

Re: [PATCH rtems-docs] eng/vc-authors: Add section on migrating personal repo to top-level

2021-06-02 Thread Gedare Bloom
looks ok On Sun, May 30, 2021 at 3:12 PM Vijay Kumar Banerjee wrote: > > --- > eng/vc-authors.rst | 46 ++ > 1 file changed, 46 insertions(+) > > diff --git a/eng/vc-authors.rst b/eng/vc-authors.rst > index dcbbeb9..179ad08 100644 > --- a/eng/vc-author

Re: [PATCH] covoar: Fix single-byte uncovered ranges

2021-06-02 Thread Gedare Bloom
ok On Wed, Jun 2, 2021 at 8:29 AM Alex White wrote: > > This fixes a bug where covoar reports uncovered ranges of size 1. When a > NOP instruction is encountered at the end of a function, the remaining > non-instruction bytes are marked as executed. The loop that marks the > remaining bytes as ex

RE: [PATCH v1 0/2] [libbsd] Install correct machine include headers

2021-06-02 Thread Jan.Sommer
Thanks, Chris & Christian. I think I got a better understanding of the issues now and found a simpler solution which is less intrusive. I will post a new patchset. Best regards, Jan > -Original Message- > From: Chris Johns > Sent: Tuesday, June 1, 2021 11:28 PM > To: Christian Maude

[PATCH] covoar: Fix single-byte uncovered ranges

2021-06-02 Thread Alex White
This fixes a bug where covoar reports uncovered ranges of size 1. When a NOP instruction is encountered at the end of a function, the remaining non-instruction bytes are marked as executed. The loop that marks the remaining bytes as executed was not considering the last address of the function. Cl