On 22.01.2024 12:05, Anthony PERARD wrote:
> On Mon, Jan 22, 2024 at 10:54:13AM +, Anthony PERARD wrote:
>> On Mon, Jan 22, 2024 at 11:04:41AM +0100, Jan Beulich wrote:
>>> On 19.01.2024 16:25, Anthony PERARD wrote:
On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
> Is my
On 22/01/2024 12:05, Anthony PERARD wrote:
>
>
> On Mon, Jan 22, 2024 at 10:54:13AM +, Anthony PERARD wrote:
>> On Mon, Jan 22, 2024 at 11:04:41AM +0100, Jan Beulich wrote:
>>> On 19.01.2024 16:25, Anthony PERARD wrote:
On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
On Mon, Jan 22, 2024 at 10:54:13AM +, Anthony PERARD wrote:
> On Mon, Jan 22, 2024 at 11:04:41AM +0100, Jan Beulich wrote:
> > On 19.01.2024 16:25, Anthony PERARD wrote:
> > > On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
> > >> Is my understanding correct that by switching
On 22.01.2024 11:54, Anthony PERARD wrote:
> On Mon, Jan 22, 2024 at 11:04:41AM +0100, Jan Beulich wrote:
>> On 19.01.2024 16:25, Anthony PERARD wrote:
>>> On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
Is my understanding correct that by switching from extra-y to targets we
On Mon, Jan 22, 2024 at 11:04:41AM +0100, Jan Beulich wrote:
> On 19.01.2024 16:25, Anthony PERARD wrote:
> > On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
> >> Is my understanding correct that by switching from extra-y to targets we
> >> are preventing these objects to
> >>
On 19.01.2024 16:25, Anthony PERARD wrote:
> On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
>> Is my understanding correct that by switching from extra-y to targets we are
>> preventing these objects to
>> appear in non-init-objects (and thus having COV_FLAGS appended) while
>>
On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
> Is my understanding correct that by switching from extra-y to targets we are
> preventing these objects to
> appear in non-init-objects (and thus having COV_FLAGS appended) while
> retaining the proper if_changed behavior?
>
>
Hi Anthony,
On 18/01/2024 18:37, Anthony PERARD wrote:
>
>
> On Thu, Jan 18, 2024 at 02:12:21PM +0100, Jan Beulich wrote:
>> On 18.01.2024 13:06, Michal Orzel wrote:
>>> At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
>>> under the hood) results in a crash. This is
On Thu, Jan 18, 2024 at 02:12:21PM +0100, Jan Beulich wrote:
> On 18.01.2024 13:06, Michal Orzel wrote:
> > At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
> > under the hood) results in a crash. This is due to an attempt to
> > access code in the .init.* sections
On 18.01.2024 15:40, Michal Orzel wrote:
> On 18/01/2024 14:12, Jan Beulich wrote:
>> On 18.01.2024 13:06, Michal Orzel wrote:
>>> At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
>>> under the hood) results in a crash. This is due to an attempt to
>>> access code in the
Hi Jan,
On 18/01/2024 14:12, Jan Beulich wrote:
>
>
> On 18.01.2024 13:06, Michal Orzel wrote:
>> At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
>> under the hood) results in a crash. This is due to an attempt to
>> access code in the .init.* sections (libfdt for Arm
On 18/01/2024 12:06 pm, Michal Orzel wrote:
> At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
> under the hood) results in a crash. This is due to an attempt to
> access code in the .init.* sections
Minor point, but for coverage it's only data. It's the per-basic-block
On 18.01.2024 13:06, Michal Orzel wrote:
> At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
> under the hood) results in a crash. This is due to an attempt to
> access code in the .init.* sections (libfdt for Arm and libelf for x86)
> that are stripped after boot.
At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
under the hood) results in a crash. This is due to an attempt to
access code in the .init.* sections (libfdt for Arm and libelf for x86)
that are stripped after boot. Normally, the build system compiles any
*.init.o file
14 matches
Mail list logo