[PATCH] covoar: Fix single-byte uncovered ranges
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.
Closes #4448
---
tester/covoar/DesiredSymbols.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tester/covoar/DesiredSymbols.cc b/tester/covoar/DesiredSymbols.cc
index 2866dbe..75ec76f 100644
--- a/tester/covoar/DesiredSymbols.cc
+++ b/tester/covoar/DesiredSymbols.cc
@@ -252,7 +252,7 @@ namespace Coverage {
do {
theCoverageMap->setWasExecuted( ha );
ha++;
-if ( ha >= endAddress )
+if ( ha > endAddress )
break;
} while ( !theCoverageMap->isStartOfInstruction( ha ) ||
theCoverageMap->isNop( ha ) );
--
2.27.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RE: [PATCH v1 0/2] [libbsd] Install correct machine include headers
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 Mauderer ; Gedare Bloom > ; Sommer, Jan > Cc: devel@rtems.org > Subject: Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers > > On 2/6/21 4:20 am, Christian Mauderer wrote: > > On 01/06/2021 19:24, Gedare Bloom wrote: > >> On Mon, May 10, 2021 at 11:26 AM Jan Sommer > wrote: > >>> > >>> Hello, > >>> > >>> This is a follow-up on this discussion regarding the installed > >>> header files in libbsd: > >>> https://lists.rtems.org/pipermail/devel/2021-April/066211.html > >>> > >>> The current situation is, that for example for all machines the > >>> bus.h is installed from within the rtemsbsd directory > >>> (https://git.rtems.org/rtems- > libbsd/tree/rtemsbsd/include/machine/bus.h). > >>> > >>> According to the file docu it originates from the amd64 version of this > file. > >>> It also has the following section in it which we ran into when > >>> compiling Chris' ptpd2 archive: > >>> > >>> #ifdef __i386__ > >>> #error "your include paths are wrong" > >>> #endif > >>> > >>> This patchset does the following: > >>> - Add the target dependent machine include directory to > >>> 'header-paths' in libbsd.py > >>> - Import (mostly) '_bus.h', 'bus.h' and 'cpufunc.h' for the targets > >>> from freebsd-org > >>> - Remove those header files from rtemsbsd directory > >>> > >>> As a result the matching versions for machine dependent header files > >>> are now installed for each BSP. > >>> Would this be an acceptable solution? > >>> > >>> So far I compiled some BSPs for i386, arm, aarch64, powerpc, riscv, > >>> sparc and > >>> sparc64 to check that they still compile after the changes. > >>> Are there any other architectures which should be included? > > > > I think the best starting point to find out the minimum supported > > platforms is the nexus-devices.h. At least the officially supported > > BSPs should have an entry there. That is: > > > > #if defined(LIBBSP_ARM_REALVIEW_PBX_A9_BSP_H) > > #elif defined(LIBBSP_ARM_BEAGLE_BSP_H) #elif > > defined(LIBBSP_ARM_LPC32XX_BSP_H) #elif > > defined(LIBBSP_M68K_GENMCF548X_BSP_H) > > #elif defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H) > > #elif defined(LIBBSP_AARCH64_XILINX_ZYNQMP_BSP_H) > > #elif defined(LIBBSP_ARM_ATSAM_BSP_H) > > #elif defined(LIBBSP_ARM_ALTERA_CYCLONE_V_BSP_H) > > #elif defined(LIBBSP_ARM_IMX_BSP_H) > > #elif defined(LIBBSP_ARM_IMXRT_BSP_H) > > #elif defined(LIBBSP_ARM_LPC24XX_BSP_H) #elif > > defined(LIBBSP_ARM_STM32H7_BSP_H) #elif > > defined(LIBBSP_I386_PC386_BSP_H) #elif > > defined(LIBBSP_POWERPC_QORIQ_BSP_H) > > #elif defined(LIBBSP_POWERPC_TQM8XX_BSP_H) > > #elif defined(LIBBSP_POWERPC_MOTOROLA_POWERPC_BSP_H) > > > > So I think you should have a look at m68k too. > > > > Did you try to run it on any of the platforms? > > > >>> > >>> I ran into one problem regarding the compilation of > >>> rtemsbsd/sys/dev/dw_mmc/dw_mmc.c:105 > >>> > return (bus_space_read_4(0, sc->bushandle, off)); > >>> > >>> The first parameter creates an error for riscv (I think because > >>> dereferencing a NULL pointer). > >>> Are there any suggestion how to solve it (I am not familiar with the > >>> bus space and there is a lot of macro magic going on)? > >>> > >> It looks like this will be a problem for any architecture. so should > >> the function that calls bus_space_write_4(0 ...) > >> The macro trail goes... > >> > >> #define __bs_rs(sz, t, h, o) > >> \ > >> (*(t)->__bs_opname(r,sz))((t)->bs_cookie, h, o) > >> > >> #define bus_space_read_4(t, h, o) __bs_rs(4,(t),(h),(o)) > >> > >> so t is dereferenced. It appears to be an error in the API usage by > >> the dw_mmc.c code to not specify a valid bus space. > > > > dw_mmc is only relevant for very few platforms. So in theory it could > > be limited to these. But most likely that won't really solve the problem. > > > > The right answer is that dw_mmc doesn't use the API like intended > > (like Gedare said). That could be a problem for more drivers that use > > stuff from bus.h in rtemsbsd. They never had to use that API > > correctly. Even worse: Some of the __rtems__ hacks in freebsd could have > that problem too. > > > > I think for this patch set we either need to have a thorough look at > > these locations or run (not only build) it on a number of platforms, > > especially the ones with special drivers in rtemsbsd or with heavily adapted > drivers. > > The only arch that supports a tag we current have is the x86 and that is for > IO > vs mem space. I posted some patches earlier this year I need to revisit for > the powerpc (mvme2700). If possible we prefer no tags and a single flat > address space that is cache coherent. In the x86 tags cannot be avoided and > supported drivers handle t
Re: [PATCH] covoar: Fix single-byte uncovered ranges
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 executed was not considering the last address of the
> function.
>
> Closes #4448
> ---
> tester/covoar/DesiredSymbols.cc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tester/covoar/DesiredSymbols.cc b/tester/covoar/DesiredSymbols.cc
> index 2866dbe..75ec76f 100644
> --- a/tester/covoar/DesiredSymbols.cc
> +++ b/tester/covoar/DesiredSymbols.cc
> @@ -252,7 +252,7 @@ namespace Coverage {
>do {
> theCoverageMap->setWasExecuted( ha );
> ha++;
> -if ( ha >= endAddress )
> +if ( ha > endAddress )
>break;
>} while ( !theCoverageMap->isStartOfInstruction( ha ) ||
> theCoverageMap->isNop( ha ) );
> --
> 2.27.0
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-docs] eng/vc-authors: Add section on migrating personal repo to top-level
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-authors.rst > +++ b/eng/vc-authors.rst > @@ -166,6 +166,52 @@ flag to prevent merge from issuing an automatic merge > commit message. > When you have committed changes on a branch that is public/shared with > another > developer you should not rebase that branch. > > +Migrate a Personal Repository to top-level > +-- > + > +Once a project is production ready in the personal repository, it's time to > +migrate it to the top-level RTEMS git directory. First, the project directory > +needs to be copied and then the permissions need to be set, so that everyone > can > +push into that repository. > + > +.. code-block:: shell > + > + cp -R /data/git/user/my-rtems-project.git /data/git > + cd /data/git/my-rtems-project.git > + chgrp -R gitrw ./ > + chmod -R g+rws ./ > + > +Then copy the post-receive script from the rtems.git directory and change the > +name of REPO. > + > +.. code-block:: shell > + > + cp /data/git/rtems.git/hooks/post-receive > /data/git/my-rtems-project.git/hooks/ > + > +After making the change the post-receive script in the new repository should > +look like this > + > +.. code-block:: shell > + > + #!/bin/sh > + # > + # The "post-receive" script is run after receive-pack has accepted a pack > + # and the repository has been updated. It is passed arguments in through > + # stdin in the form > + # > + # For example: > + # aa453216d1b3e49e7f6f98441fa56946ddcd6a20 > 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master > + # > + > + REPO=my-rtems-project > + > + . /data/support/git-support/hooks/post-receive-0 > + . /data/support/git-support/hooks/post-receive-1 > + #. /data/support/git-support/hooks/post-receive-2 > + . /data/support/git-support/hooks/post-receive-3 > + . /data/support/git-support/hooks/post-receive-4 > + . /data/support/git-support/hooks/post-receive-5 > + > GIT Push Configuration > -- > > -- > 2.26.2 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/libdebugger: Fix for sockaddr_in not being initialized
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
>> ---
>> cpukit/libdebugger/rtems-debugger-remote-tcp.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/cpukit/libdebugger/rtems-debugger-remote-tcp.c
>> b/cpukit/libdebugger/rtems-debugger-remote-tcp.c
>> index 696e2deb8c..440baa9b66 100644
>> --- a/cpukit/libdebugger/rtems-debugger-remote-tcp.c
>> +++ b/cpukit/libdebugger/rtems-debugger-remote-tcp.c
>> @@ -122,7 +122,7 @@ static int
>> tcp_remote_connect(rtems_debugger_remote* remote)
>> {
>>intld;
>> - struct sockaddr_in addr;
>> + struct sockaddr_in addr = {0};
>>socklen_t opt;
>>socklen_t len;
>>bool running;
>> --
>> 2.25.1
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-docs] eng/vc-authors: Add section on migrating personal repo to top-level
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-authors.rst b/eng/vc-authors.rst > > index dcbbeb9..179ad08 100644 > > --- a/eng/vc-authors.rst > > +++ b/eng/vc-authors.rst > > @@ -166,6 +166,52 @@ flag to prevent merge from issuing an automatic merge > > commit message. > > When you have committed changes on a branch that is public/shared with > > another > > developer you should not rebase that branch. > > > > +Migrate a Personal Repository to top-level > > +-- > > + > > +Once a project is production ready in the personal repository, it's time to > > +migrate it to the top-level RTEMS git directory. First, the project > > directory > > +needs to be copied and then the permissions need to be set, so that > > everyone can > > +push into that repository. > > + > > +.. code-block:: shell > > + > > + cp -R /data/git/user/my-rtems-project.git /data/git > > + cd /data/git/my-rtems-project.git > > + chgrp -R gitrw ./ > > + chmod -R g+rws ./ > > + > > +Then copy the post-receive script from the rtems.git directory and change > > the > > +name of REPO. > > + > > +.. code-block:: shell > > + > > + cp /data/git/rtems.git/hooks/post-receive > > /data/git/my-rtems-project.git/hooks/ > > + > > +After making the change the post-receive script in the new repository > > should > > +look like this > > + > > +.. code-block:: shell > > + > > + #!/bin/sh > > + # > > + # The "post-receive" script is run after receive-pack has accepted a pack > > + # and the repository has been updated. It is passed arguments in through > > + # stdin in the form > > + # > > + # For example: > > + # aa453216d1b3e49e7f6f98441fa56946ddcd6a20 > > 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master > > + # > > + > > + REPO=my-rtems-project > > + > > + . /data/support/git-support/hooks/post-receive-0 > > + . /data/support/git-support/hooks/post-receive-1 > > + #. /data/support/git-support/hooks/post-receive-2 > > + . /data/support/git-support/hooks/post-receive-3 > > + . /data/support/git-support/hooks/post-receive-4 > > + . /data/support/git-support/hooks/post-receive-5 > > + > > GIT Push Configuration > > -- > > > > -- > > 2.26.2 > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Selection of ethernet peripheral by application
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 interface and I need to have the option of selecting a different peripheral as the primary interface. Unfortunately, the current configuration of LibBSD/RTEMS does not allow for easy switching among the available interfaces. The easy one-off option is to just create a BSP variant with a little bit of extra logic to select the correct interface in LibBSD, but this problem seems more generally applicable than just ethernet and just this one BSP. Is the best alternative to configure all available devices in nexus-devices.h and let LibBSD figure it out? Thanks, Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Selection of ethernet peripheral by application
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 Ultrascale+ MPSoC dev boards) use CGEM3 as the only/primary > ethernet interface and I > > need to have the option of selecting a different peripheral as the primary > interface. > > > > Unfortunately, the current configuration of LibBSD/RTEMS does not allow > for easy switching among the > > available interfaces. The easy one-off option is to just create a BSP > variant with a little bit of extra logic > > to select the correct interface in LibBSD, but this problem seems more > generally applicable than just > > ethernet and just this one BSP. Is the best alternative to configure all > available devices in > > nexus-devices.h and let LibBSD figure it out? > Thinking out loud. The first order selection of the driver is the LIBBSD_ABC header guard to select a BSP. Some BSPs have a second ifdef. I think qoriq is an example. But this would require adding a BSP configure option or variant. --joel > > > Thanks, > Kinsey > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2] covoar: Store address-to-line info outside of DWARF
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 | 5 +
rtemstoolkit/rld-dwarf.h | 5 +
tester/covoar/AddressToLineMapper.cc | 104 +
tester/covoar/AddressToLineMapper.h | 211 +++
tester/covoar/ExecutableInfo.cc | 73 +
tester/covoar/ExecutableInfo.h | 11 +-
tester/covoar/wscript| 1 +
7 files changed, 368 insertions(+), 42 deletions(-)
create mode 100644 tester/covoar/AddressToLineMapper.cc
create mode 100644 tester/covoar/AddressToLineMapper.h
diff --git a/rtemstoolkit/rld-dwarf.cpp b/rtemstoolkit/rld-dwarf.cpp
index 2fce0e4..1eae50c 100644
--- a/rtemstoolkit/rld-dwarf.cpp
+++ b/rtemstoolkit/rld-dwarf.cpp
@@ -1893,6 +1893,11 @@ namespace rld
return false;
}
+const addresses& compilation_unit::get_addresses () const
+{
+ return addr_lines_;
+}
+
functions&
compilation_unit::get_functions ()
{
diff --git a/rtemstoolkit/rld-dwarf.h b/rtemstoolkit/rld-dwarf.h
index 1210813..eadb50d 100644
--- a/rtemstoolkit/rld-dwarf.h
+++ b/rtemstoolkit/rld-dwarf.h
@@ -707,6 +707,11 @@ namespace rld
*/
unsigned int pc_high () const;
+ /**
+ * The addresses associated with this compilation unit.
+ */
+ const addresses& get_addresses () const;
+
/**
* Get the source and line for an address. If the address does not match
* false is returned the file is set to 'unknown' and the line is set to
diff --git a/tester/covoar/AddressToLineMapper.cc
b/tester/covoar/AddressToLineMapper.cc
new file mode 100644
index 000..c305e3b
--- /dev/null
+++ b/tester/covoar/AddressToLineMapper.cc
@@ -0,0 +1,104 @@
+/*! @file AddressToLineMapper.cc
+ * @brief AddressToLineMapper Implementation
+ *
+ * This file contains the implementation of the functionality
+ * of the AddressToLineMapper class.
+ */
+
+#include "AddressToLineMapper.h"
+
+namespace Coverage {
+
+ uint64_t SourceLine::location() const
+ {
+return address;
+ }
+
+ bool SourceLine::is_an_end_sequence() const
+ {
+return is_end_sequence;
+ }
+
+ const std::string& SourceLine::path() const
+ {
+return path_;
+ }
+
+ int SourceLine::line() const
+ {
+return line_num;
+ }
+
+ void AddressLineRange::addSourceLine(const rld::dwarf::address& address)
+ {
+auto insertResult = sourcePaths.insert(address.path());
+
+sourceLines.emplace_back(
+ SourceLine (
+address.location(),
+*insertResult.first,
+address.line(),
+address.is_an_end_sequence()
+ )
+);
+ }
+
+ const SourceLine& AddressLineRange::getSourceLine(uint32_t address) const
+ {
+if (address < lowAddress || address > highAddress) {
+ throw SourceNotFoundError(std::to_string(address));
+}
+
+const SourceLine* last_line = nullptr;
+for (const auto &line : sourceLines) {
+ if (address <= line.location())
+ {
+if (address == line.location())
+ last_line = &line;
+break;
+ }
+ last_line = &line;
+}
+
+if (last_line == nullptr) {
+ throw SourceNotFoundError(std::to_string(address));
+}
+
+return *last_line;
+ }
+
+ void AddressToLineMapper::getSource(
+uint32_t address,
+std::string& sourceFile,
+int& sourceLine
+ ) const {
+const SourceLine default_sourceline = SourceLine();
+const SourceLine* match = &default_sourceline;
+
+for (const auto &range : addressLineRanges) {
+ try {
+const SourceLine& potential_match = range.getSourceLine(address);
+
+if (match->is_an_end_sequence() ||
!potential_match.is_an_end_sequence()) {
+ match = &potential_match;
+}
+ } catch (const AddressLineRange::SourceNotFoundError&) {}
+}
+
+sourceFile = match->path();
+sourceLine = match->line();
+ }
+
+ AddressLineRange& AddressToLineMapper::makeRange(
+uint32_t low,
+uint32_t high
+ )
+ {
+addressLineRanges.emplace_back(
+ AddressLineRange(low, high)
+);
+
+return addressLineRanges.back();
+ }
+
+}
diff --git a/tester/covoar/AddressToLineMapper.h
b/tester/covoar/AddressToLineMapper.h
new file mode 100644
index 000..e6ab4a8
--- /dev/null
+++ b/tester/covoar/AddressToLineMapper.h
@@ -0,0 +1,211 @@
+/*! @file AddressToLineMapper.h
+ * @brief AddressToLineMapper Specification
+ *
+ * This file contains the specification of the AddressToLineMapper class.
+ */
+
+#ifndef __ADDRESS_TO_LINE_MAPPER_H__
+#define __ADDRESS_TO_LINE_MAPPER_H__
+
+#include
+#include
+#include
+#include
+
+#include
+
+namespace Coverage {
+
+ /*! @class SourceLine
+ *
+ * This class stores source information for a specific address.
+ */
+ cl
Re: Selection of ethernet peripheral by application
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+ MPSoC dev boards) use CGEM3 as the only/primary > ethernet interface and I > > need to have the option of selecting a different peripheral as the primary > interface. > > > > Unfortunately, the current configuration of LibBSD/RTEMS does not allow for > easy > switching among the > > available interfaces. The easy one-off option is to just create a BSP variant > with a little bit of extra logic > > to select the correct interface in LibBSD, but this problem seems more > generally > applicable than just > > ethernet and just this one BSP. Is the best alternative to configure all > available devices in > > nexus-devices.h and let LibBSD figure it out? I am not sure what the issue is. I also do not know what is "the correct interface" means. How many interfaces do you need to support and what are they? If a device like the Ultrascale as 2 hard IP GEM MACs maybe LibBSD for that BSP should enable both by default. Maybe the Zynq and Versal (when added) should be the same. If a user adds another MAC in the PL, for example a Tri-Core LogicCore block (and adds a driver) then there may be 3 interfaces present but that would not be enabled by default. The same goes for the PC with the ability to plug in NIC boards. What happens after probing and the drivers are present is for the application to manage via the stack's various interfaces. The rc.conf support I added uses commands such as ifconfig to access those interfaces and provide support for initialisation and set up. There are other ways that could be done. I wonder if there is a misunderstanding and it could be on my part. LibBSD does not ship with THE defined set of interfaces. It has a minimal set to allow testing and maybe that is wrong. A lot of the testing framework is just that a testing framework and if you wish to leverage that support in applications then all the best because that support can and may change to suite the testing needs of LibBSD and there is no requirement to make it backwards compatible for application that depend on it. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] covoar: Store address-to-line info outside of DWARF
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 leads to significant memory savings.
>
> Closes #4383
> ---
> rtemstoolkit/rld-dwarf.cpp | 5 +
> rtemstoolkit/rld-dwarf.h | 5 +
> tester/covoar/AddressToLineMapper.cc | 104 +
> tester/covoar/AddressToLineMapper.h | 211 +++
> tester/covoar/ExecutableInfo.cc | 73 +
> tester/covoar/ExecutableInfo.h | 11 +-
> tester/covoar/wscript| 1 +
> 7 files changed, 368 insertions(+), 42 deletions(-)
> create mode 100644 tester/covoar/AddressToLineMapper.cc
> create mode 100644 tester/covoar/AddressToLineMapper.h
>
> diff --git a/rtemstoolkit/rld-dwarf.cpp b/rtemstoolkit/rld-dwarf.cpp
> index 2fce0e4..1eae50c 100644
> --- a/rtemstoolkit/rld-dwarf.cpp
> +++ b/rtemstoolkit/rld-dwarf.cpp
> @@ -1893,6 +1893,11 @@ namespace rld
>return false;
> }
>
> +const addresses& compilation_unit::get_addresses () const
> +{
> + return addr_lines_;
> +}
> +
> functions&
> compilation_unit::get_functions ()
> {
> diff --git a/rtemstoolkit/rld-dwarf.h b/rtemstoolkit/rld-dwarf.h
> index 1210813..eadb50d 100644
> --- a/rtemstoolkit/rld-dwarf.h
> +++ b/rtemstoolkit/rld-dwarf.h
> @@ -707,6 +707,11 @@ namespace rld
> */
>unsigned int pc_high () const;
>
> + /**
> + * The addresses associated with this compilation unit.
> + */
> + const addresses& get_addresses () const;
> +
>/**
> * Get the source and line for an address. If the address does not
> match
> * false is returned the file is set to 'unknown' and the line is set
> to
> diff --git a/tester/covoar/AddressToLineMapper.cc
> b/tester/covoar/AddressToLineMapper.cc
> new file mode 100644
> index 000..c305e3b
> --- /dev/null
> +++ b/tester/covoar/AddressToLineMapper.cc
> @@ -0,0 +1,104 @@
> +/*! @file AddressToLineMapper.cc
> + * @brief AddressToLineMapper Implementation
> + *
> + * This file contains the implementation of the functionality
> + * of the AddressToLineMapper class.
> + */
> +
> +#include "AddressToLineMapper.h"
> +
> +namespace Coverage {
> +
> + uint64_t SourceLine::location() const
> + {
> +return address;
> + }
> +
> + bool SourceLine::is_an_end_sequence() const
> + {
> +return is_end_sequence;
> + }
> +
> + const std::string& SourceLine::path() const
> + {
> +return path_;
> + }
> +
> + int SourceLine::line() const
> + {
> +return line_num;
> + }
> +
> + void AddressLineRange::addSourceLine(const rld::dwarf::address& address)
> + {
> +auto insertResult = sourcePaths.insert(address.path());
> +
> +sourceLines.emplace_back(
> + SourceLine (
> +address.location(),
> +*insertResult.first,
> +address.line(),
> +address.is_an_end_sequence()
> + )
> +);
> + }
> +
> + const SourceLine& AddressLineRange::getSourceLine(uint32_t address) const
> + {
> +if (address < lowAddress || address > highAddress) {
> + throw SourceNotFoundError(std::to_string(address));
> +}
> +
> +const SourceLine* last_line = nullptr;
> +for (const auto &line : sourceLines) {
> + if (address <= line.location())
> + {
> +if (address == line.location())
> + last_line = &line;
> +break;
> + }
> + last_line = &line;
> +}
> +
> +if (last_line == nullptr) {
> + throw SourceNotFoundError(std::to_string(address));
> +}
> +
> +return *last_line;
> + }
How often is this function being called? If it is a hot spot are there other
ways to search for the address? I suppose it depends on the number of lines in
the vector.
If the sourcesLines vector was sorted can this loop be replaced with some form
of std::upper_bound? That is ...
auto last_line =
std::upper_bound(sourceLines.begin(),
sourceLines.end(),
address,
[&address](const SourceLine& sl) {
return address < sl.location();
});
[ not sure if the code I posted would work and if I got the lamda right :) ]
Just wondering.
Chris
> +
> + void AddressToLineMapper::getSource(
> +uint32_t address,
> +std::string& sourceFile,
> +int& sourceLine
> + ) const {
> +const SourceLine default_sourceline = SourceLine();
> +const SourceLine* match = &default_sourceline;
> +
> +for (const auto &range : addressLineRanges) {
> + try {
> +const SourceLine& potential_match = range.getSourceLine(address);
> +
> +if (match->is_an_end_sequence() ||
> !potential_match.is_an_end_sequence()) {
> + match = &potential_match;
> +
