Fwd: Undelivered Mail Returned to Sender

Fwd: Undelivered Mail Returned to Sender

[Torbjorn SVENSSON]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

Hello,

FYI, it looks like there is an issue with the mail system at 
sourceware.org (maybe this mail wont be delivered either...).

Kind regards,
Torbjörn



-------- Forwarded Message --------
Subject: Undelivered Mail Returned to Sender
Date: Fri, 21 Oct 2022 19:13:25 +0000
From: Mail Delivery System <MAILER-DAEMON@sourceware.org>
To: prvs=6293993ff7=torbjorn.svensson@foss.st.com

This is the mail system at host sourceware.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                    The mail system

<inbox@sourceware.org> (expanded from <gdb-patches@sourceware.org>): Command
     time limit exceeded: "/home/inbox/public-inbox-mda-true.sh"

[-- Attachment #2: Attached Message Part --]
[-- Type: message/delivery-status, Size: 371 bytes --]

[-- Attachment #3: ForwardedMessage.eml --]
[-- Type: message/rfc822, Size: 10476 bytes --]

From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
To: Luis Machado <luis.machado@arm.com>, Tomas Vanek <vanekt@fbl.cz>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH v3] gdb/arm: Terminate frame unwinding in M-profile lockup state
Date: Fri, 21 Oct 2022 20:56:32 +0200
Message-ID: <33a3ce23-b2db-a1b0-01d3-8a3e9668495e@foss.st.com>

Hi,

On 2022-10-21 11:20, Luis Machado wrote:
> On 10/17/22 20:30, Tomas Vanek wrote:
>> In the lockup state the PC value of the the outer frame is irreversibly
>> lost. The other registers are intact so LR likely contains
>> PC of some frame next to the outer one, but we cannot analyze
>> the nearest outer frame without knowing its PC
>> therefore we do not know SP fixup for this frame.
>>
>> The frame unwinder possibly gets mad due to the wrong SP value.
>> To prevent problems terminate unwinding if PC contains the magic
>> value of the lockup state.
>>
>> Example session wihtout this change,
>> Cortex-M33 CPU in lockup, gdb 13.0.50.20221016-git:
>> ----------------
>>    (gdb) c
>>    Continuing.
>>
>>    Program received signal SIGINT, Interrupt.
>>    0xeffffffe in ?? ()
>>    (gdb) bt
>>    #0  0xeffffffe in ?? ()
>>    #1  0x0c000a9c in HardFault_Handler ()
>>        at 
>> C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:99
>>    #2  0x2002ffd8 in ?? ()
>>    Backtrace stopped: previous frame identical to this frame (corrupt 
>> stack?)
>>    (gdb)
>> ----------------
>> The frame #1 is at correct PC taken from LR, #2 is a total nonsense.
>>
>> With the change:
>> ----------------
>>    (gdb) c
>>    Continuing.
>>
>>    Program received signal SIGINT, Interrupt.
>>    warning: ARM M in lockup state, stack unwinding terminated.
>>    <signal handler called>
>>    (gdb) bt
>>    #0  <signal handler called>
>>    (gdb)
>> ----------------
>>
>> There is a visible drawback of emitting a warning in a cache buildnig 
>> routine
>> as introduced in Torbjörn SVENSSON's
>> [PATCH v4] gdb/arm: Stop unwinding on error, but do not assert
>> The warning is printed just once and not repeated on each backtrace 
>> command.
>>
>> v2 update: warning supressed for other frames than the innermost one.
>> v3 update: boolean values and comment fixes
>>
>> Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
>> ---
>>   gdb/arm-tdep.c | 55 
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++---
>>   1 file changed, 52 insertions(+), 3 deletions(-)
>>
>> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
>> index b5facae..aefd241 100644
>> --- a/gdb/arm-tdep.c
>> +++ b/gdb/arm-tdep.c
>> @@ -724,9 +724,30 @@ class target_arm_instruction_reader : public 
>> arm_instruction_reader
>>     return 0;
>>   }
>> +static inline bool
>> +arm_m_addr_is_lockup (CORE_ADDR addr)
>> +{
>> +  switch (addr)
>> +    {
>> +      /* Values for lockup state.
>> +     For more details see "B1.5.15 Unrecoverable exception cases" in
>> +     both ARMv6-M and ARMv7-M Architecture Reference Manuals, or
>> +     see "B4.32 Lockup" in ARMv8-M Architecture Reference Manual.  */
>> +      case 0xeffffffe:

Just a minor question:
I think the documentation mentioned that the last bit can be either 0 or 
1 and they should both be considered the same instruction as the bit is 
only for thumb mode. Maybe we should also list 0xefffffff?

>> +      case 0xfffffffe:
>> +      case 0xffffffff:
>> +    return true;
>> +
>> +      default:
>> +    /* Address is not lockup.  */
>> +    return false;
>> +    }
>> +}
>> +
>>   /* Determine if the address specified equals any of these magic return
>>      values, called EXC_RETURN, defined by the ARM v6-M, v7-M and v8-M
>> -   architectures.
>> +   architectures. Also include lockup magic PC value.
> 
> Formatting: Two spaces after '.'
> 
>> +   Check also for FNC_RETURN if we have v8-M security extension.
> 
> we have -> we have the
> 
>>      From ARMv6-M Reference Manual B1.5.8
>>      Table B1-5 Exception return behavior
>> @@ -769,6 +790,9 @@ class target_arm_instruction_reader : public 
>> arm_instruction_reader
>>   static int
>>   arm_m_addr_is_magic (struct gdbarch *gdbarch, CORE_ADDR addr)
>>   {
>> +  if (arm_m_addr_is_lockup (addr))
>> +    return 1;
>> +
>>     arm_gdbarch_tdep *tdep = gdbarch_tdep<arm_gdbarch_tdep> (gdbarch);
>>     if (tdep->have_sec_ext)
>>       {
>> @@ -3355,6 +3379,30 @@ struct frame_unwind arm_stub_unwind = {
>>        describes which bits in LR that define which stack was used prior
>>        to the exception and if FPU is used (causing extended stack 
>> frame).  */
>> +  /* In the lockup state PC contains a lockup magic value.
>> +     The PC value of the the next outer frame is irreversibly
>> +     lost. The other registers are intact so LR likely contains
> 
> Formatting: Two spaces after '.'.
> 
>> +     PC of some frame next to the outer one, but we cannot analyze
>> +     the next outer frame without knowing its PC
>> +     therefore we do not know SP fixup for this frame.
>> +     Some heuristics to resynchronize SP might be possible.
>> +     For simplicity just terminate unwinding to prevent the unwinder
>> +     going mad.  */
> 
> How about...
> 
> For simplicity, just terminate the unwinding to prevent it going astray and
> attempting to read data/addresses it shouldn't, which may cause further 
> issues due
> to side-effects.
> 
> Does that make sense?
> 
>> +  CORE_ADDR pc = get_frame_pc (this_frame);
>> +  if (arm_m_addr_is_lockup (pc))
>> +    {
>> +      /* The lockup can be real just in the innermost frame
>> +     as the CPU is stopped and cannot create more frames.
>> +     If we hit lockup magic PC in the other frame, it is
>> +     just a sentinel at the top of stack: do not warn then.  */
>> +      if (frame_relative_level (this_frame) == 0)
>> +    warning (_("ARM M in lockup state, stack unwinding terminated."));
>> +
>> +      /* Terminate any further stack unwinding.  */
>> +      arm_cache_set_active_sp_value (cache, tdep, 0);
>> +      return cache;
>> +    }
>> +
>>     CORE_ADDR lr = get_frame_register_unsigned (this_frame, 
>> ARM_LR_REGNUM);
>>     /* ARMv7-M Architecture Reference "A2.3.1 Arm core registers"
>> @@ -3824,11 +3872,12 @@ struct frame_unwind arm_stub_unwind = {
>>     return arm_m_addr_is_magic (gdbarch, this_pc);
>>   }
>> -/* Frame unwinder for M-profile exceptions.  */
>> +/* Frame unwinder for M-profile exceptions (EXC_RETURN on stack),
>> +   lockup and secure/nonsecure interstate function calls 
>> (FNC_RETURN).  */
>>   struct frame_unwind arm_m_exception_unwind =
>>   {
>> -  "arm m exception",
>> +  "arm m exception lockup sec_fnc",
>>     SIGTRAMP_FRAME,
>>     arm_m_exception_frame_unwind_stop_reason,
>>     arm_m_exception_this_id,
> 
> Torbjörn, have you managed to exercise this on your end? Does it behave 
> as expected (stops unwinding gracefully)?

I've tested it a bit on a STM32F4-Discovery board and it works better 
than current HEAD. Based on this board, I'd say LGTM.

> 
>  From looking at the code, this looks OK to me, but I don't have the 
> proper setup to exercise it.

Re: Fwd: Undelivered Mail Returned to Sender

[Frank Ch. Eigler]

Hi -

> FYI, it looks like there is an issue with the mail system at sourceware.org
> (maybe this mail wont be delivered either...).

Thanks, we tweaked two related things, pls let us know if this reoccurs.

- FChE

Re: Fwd: Undelivered Mail Returned to Sender

[Torbjorn SVENSSON]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

Hi again,

On 2022-10-21 21:45, Frank Ch. Eigler wrote:
> Hi -
> 
>> FYI, it looks like there is an issue with the mail system at sourceware.org
>> (maybe this mail wont be delivered either...).
> 
> Thanks, we tweaked two related things, pls let us know if this reoccurs.

I just noticed another failure (attached), identical to the one yesterday.

Kind regards,
Torbjörn

> 
> - FChE
> 

[-- Attachment #2: Undelivered Mail Returned to Sender.eml --]
[-- Type: message/rfc822, Size: 14612 bytes --]

[-- Attachment #2.1.1: Notification --]
[-- Type: text/plain, Size: 521 bytes --]

This is the mail system at host sourceware.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<inbox@sourceware.org> (expanded from <gdb-patches@sourceware.org>): Command
    time limit exceeded: "/home/inbox/public-inbox-mda-true.sh"

[-- Attachment #2.1.2: Delivery report --]
[-- Type: message/delivery-status, Size: 371 bytes --]

[-- Attachment #2.1.3: Undelivered Message --]
[-- Type: message/rfc822, Size: 9150 bytes --]

From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
To: Tomas Vanek <vanekt@fbl.cz>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH v2] gdb/arm: Fix M-profile EXC_RETURN exception_domain_is_secure logic
Date: Sat, 22 Oct 2022 10:11:28 +0200
Message-ID: <48df83b6-054f-6d0b-c1e3-076eef904eb3@foss.st.com>

Hi Tomas,

On 2022-10-22 10:07, Tomas Vanek wrote:
> Arm v8-M Architecture Reference Manual,
> D1.2.95 EXC_RETURN, Exception Return Payload
> describes ES bit:
> 
> "ES, bit [0]
>       Exception Secure. The security domain the exception was taken to.
>       The possible values of this bit are:
>         0 Non-secure.
>         1 Secure"
> 
> arm-tdep.c:3443, arm_m_exception_cache () function tests this bit:
> 
>    exception_domain_is_secure = (bit (lr, 0) == 0);
> 
> The test is negated!

Good catch! I'm not sure how I thought when I wrote this, but thanks for 
correcting it.

> 
> Later on line 3553, the condition evaluates if an additional state
> context is stacked:
> 
>    /* With the Security extension, the hardware saves R4..R11 too.  */
>    if (tdep->have_sec_ext && secure_stack_used
>        && (!default_callee_register_stacking || exception_domain_is_secure))
> 
> RM, B3.19 Exception entry, context stacking
> reads:
> RPLHM "In a PE with the Security Extension, on taking an exception,
> the PE hardware:
>    ...
>    2. If exception entry requires a transition from Secure state to
>       Non-secure state, the PE hardware extends the stack frame and also
>       saves additional state context."
> 
> So we should test for !exception_domain_is_secure instead of non-negated
> value!
> These two bugs compensate each other so unstacking works correctly.
> 
> But another test of exception_domain_is_secure (negated due to the
> first bug) prevents arm_unwind_secure_frames to work as expected:
> 
>    /* Unwinding from non-secure to secure can trip security
>       measures.  In order to avoid the debugger being
>       intrusive, rely on the user to configure the requested
>       mode.  */
>    if (secure_stack_used && !exception_domain_is_secure
>        && !arm_unwind_secure_frames)
> 
> Test with GNU gdb (GDB) 13.0.50.20221016-git.
> Stopped in a non-secure handler:
> 
>   (gdb) set arm unwind-secure-frames 0
>   (gdb) bt
>   #0  HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:490
>   #1  0x0804081c in SysTick_Handler ()
>       at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsstm32l5xx_it.c:134
>   #2  <signal handler called>
>   #3  HAL_GPIO_ReadPin (GPIOx=0x52020800, GPIO_Pin=8192)
>       at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Drivers/STM32L5xx_HAL_Driver/Src/stm32l5xx_hal_gpio.c:386
>   #4  0x0c000338 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:86
>   #5  0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278
>   Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> The frames #3 and #4 are secure. backtrace should stop before #3.
> 
> Stopped in a secure handler:
> 
>   (gdb) bt
>   #0  HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425
>   #1  0x0c000b6a in SysTick_Handler ()
>       at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234
>   warning: Non-secure to secure stack unwinding disabled.
>   #2  <signal handler called>
> 
> The exception from secure to secure erroneously stops unwinding. It should
> continue as far as the security unlimited backtrace:
> 
>   (gdb) set arm unwind-secure-frames 1
>   (gdb) si <-- used to rebuild frame cache after change of unwind-secure-frames

Is there any way to make gdb rebuild the frame cache directly when doing 
the "set arm unwind-secure-frames"? Feels dirty to do a instruction step 
just to get the right trace...
Regardless of the answer to the above question, it's not something to 
address in this patch.

>   0x0c0008e6      425       if (SecureTimingDelay != 0U)
>   (gdb) bt
>   #0  0x0c0008e6 in HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425
>   #1  0x0c000b6a in SysTick_Handler ()
>       at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234
>   #2  <signal handler called>
>   #3  0x0c000328 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:88
>   #4  0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278
> 
>   Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Set exception_domain_is_secure to the value expected by its name.
> Fix exception_domain_is_secure usage in the additional state context
> stacking condition.
> 
> v2: Corrected backtrace logs in commit message
> 
> Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
> ---
>   gdb/arm-tdep.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
> index 55295e1..20b6f3f 100644
> --- a/gdb/arm-tdep.c
> +++ b/gdb/arm-tdep.c
> @@ -3496,7 +3496,7 @@ struct frame_unwind arm_stub_unwind = {
>   	{
>   	  secure_stack_used = (bit (lr, 6) != 0);
>   	  default_callee_register_stacking = (bit (lr, 5) != 0);
> -	  exception_domain_is_secure = (bit (lr, 0) == 0);
> +	  exception_domain_is_secure = (bit (lr, 0) != 0);
>   
>   	  /* Unwinding from non-secure to secure can trip security
>   	     measures.  In order to avoid the debugger being
> @@ -3606,7 +3606,7 @@ struct frame_unwind arm_stub_unwind = {
>   
>         /* With the Security extension, the hardware saves R4..R11 too.  */
>         if (tdep->have_sec_ext && secure_stack_used
> -	  && (!default_callee_register_stacking || exception_domain_is_secure))
> +	  && (!default_callee_register_stacking || !exception_domain_is_secure))
>   	{
>   	  /* Read R4..R11 from the integer callee registers.  */
>   	  cache->saved_regs[4].set_addr (unwound_sp + 0x08);

Kind regards,
Torbjörn

Re: Fwd: Undelivered Mail Returned to Sender

[Mark Wielaard]

Hi Torbjorn,

On Sat, Oct 22, 2022 at 10:37:05AM +0200, Torbjorn SVENSSON via Overseers wrote:
> On 2022-10-21 21:45, Frank Ch. Eigler wrote:
> > > FYI, it looks like there is an issue with the mail system at sourceware.org
> > > (maybe this mail wont be delivered either...).
> > 
> > Thanks, we tweaked two related things, pls let us know if this reoccurs.
> 
> I just noticed another failure (attached), identical to the one yesterday.

Seems like gdb-patches is just a little bit too big and some resource
constrainst still kick in (it also looks like the last issue caused
the search database to get corrupted).

I'll reimport gdb-patches into public-inbox for just the last 12 years
(currently it contains everything since 1997). That should keep the
size of the git packs, indexes and search database under control.

Note that this error just means that the message wasn't properly
imported into public-inbox at inbox.sourceware.org. The message was
still delivered to the list. Still annoying of course.

Sorry for the inconvenience.

Cheers,

Mark

Fwd: Undelivered Mail Returned to Sender

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 305 bytes --]

Email bounce was returned to me instead of newlib by gandi.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

[-- Attachment #2: Undelivered Mail Returned to Sender --]
[-- Type: message/rfc822, Size: 10447 bytes --]

[-- Attachment #2.1.1: Notification --]
[-- Type: text/plain, Size: 589 bytes --]

This is the mail system at host fx303.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<nbrunie@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <nbrunie@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2.1.2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Attachment #2.1.3: Undelivered Message --]
[-- Type: message/rfc822, Size: 6322 bytes --]

From: Brian Inglis <Brian.Inglis@systematicsw.ab.ca>
To: newlib@sourceware.org
Subject: Re: [PATCH] Remove unnecessary parentheses around declarator
Date: Thu, 22 Jul 2021 20:14:41 -0600
Message-ID: <8cce702b-0efd-f271-7508-4237e9f2812d@SystematicSw.ab.ca>

On 2021-07-22 15:41, Maxim Blinov wrote:
> riscv64-unknown-elf-g++-11.1.0 regression suite reports the following
> failures for
> 
> $ make check-gcc-c++ RUNTESTFLAGS='dg.exp=Wstringop-overflow-6.C'
> 
> ```
> FAIL: g++.dg/warn/Wstringop-overflow-6.C  -std=gnu++14 (test for excess errors)
> FAIL: g++.dg/warn/Wstringop-overflow-6.C  -std=gnu++17 (test for excess errors)
> FAIL: g++.dg/warn/Wstringop-overflow-6.C  -std=gnu++2a (test for excess errors)
> UNSUPPORTED: g++.dg/warn/Wstringop-overflow-6.C  -std=gnu++98
> ```
> 
> The "excess errors" being
> 
> ```
> output is In file included from /home/maxim/prj/riscv-upstream/install/riscv64-unknown-elf/include/wchar.h:6,
>                   from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/cwchar:44,
>                   from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/bits/postypes.h:40,
>                   from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/iosfwd:40,
>                   from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/ios:38,
>                   from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/ostream:38,
>                   from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/iostream:39,
>                   from /home/maxim/prj/riscv-upstream/gcc-11.1.0/gcc/testsuite/g++.dg/warn/Wstringop-overflow-6.C:6:
> /home/maxim/prj/riscv-upstream/install/riscv64-unknown-elf/include/sys/reent.h:685:11: warning: unnecessary parentheses in declaration of '_sig_func' [-Wparentheses]
> ```
> ---
>   newlib/libc/include/sys/reent.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/newlib/libc/include/sys/reent.h b/newlib/libc/include/sys/reent.h
> index 6e55e1c1f..34aff863a 100644
> --- a/newlib/libc/include/sys/reent.h
> +++ b/newlib/libc/include/sys/reent.h
> @@ -677,7 +677,7 @@ struct _reent
>   # endif
>   
>     /* signal info */
> -  void (**(_sig_func))(int);
> +  void (**_sig_func)(int);
>   
>     /* These are here last so that __FILE can grow without changing the offsets
>        of the above members (on the off chance that future binary compatibility
> 

Such "unnecessary" parentheses are often specified to force functions to 
be called and disallow macro substitution.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]