This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix exception unwinding for ARM Cortex-M

Not much development happens on the Arm port of GDB these days, so getting unwinding support in would be useful and much appreciated.  I have on my backlog a plan to switch the Arm port to the newer way of doing target descriptions - I suspect that might help your patches.

I’m happy to take a look at what you had. To save time and to make things easier, for the remaining patches that are still outstanding could you please either repost them or provide some links to where they were posted. Also, so as not to just repeat the original discussions, what were the outstanding objections with them?


> On 10 Jun 2019, at 22:24, James-Adam Renquinha Henri <> wrote:
> Hi everyone in this thread, (not many as I see)
> We could take another shot at integrating some changes to GDB so it works correctly, but that may only happen if there are the least amount of useless bike-shedding and that the right people in the mailing list contribute.
> Basically, we must 1) make *very* clear the fact that Cortex-M devices are used typically in a bare-metal system with no OS (read: Linux) whatsoever, only possibly a tiny scheduler and that's all. That means we don't have to be concerned about "user visible" registers and whatnot, they are all visible anyway, and if the spec says that a register exists, *it is visible*, period. Other thing though, 2) my patch achieved its goal in a rather weaselly way, and the correct way is indeed to have it integrated into target features. But I need more info on the matter, and I'm a bit clueless about what to do with those "target features", how they are handled by GDB and how I can test the new configuration in isolation, without being "altered" by e.g. OpenOCD, which handily provides a target description that I can use as I did before.
> I sure can figure it out all by myself, but that might be only after pouring an rather big amount of time into the matter that I cannot afford to do now. I need active collaboration and answers.
> Here, let that message be in the mailing list for everyone to see.
> James-Adam Renquinha Henri, Ing. jr
> Ingénieur d'application
> On 19-06-02 03 h 31, Fredrik Hederstierna wrote:
>> Hi Yao, Adam,
>> Some years back there was done some work done on unwinding on Cortex-M.
>> Only the very first start of the chain of patches was completed (new function arm_m_pc_is_magic()).
>> The actual real patch work with code work by me/Adam for cortex-M4F MSP/PSP and unwinding did never reached the repo.
>> What do you think of making another attempt to fix the stuff, I guess all paper-work etc is in place, so we can try do a retake on this?
>> Thanks, Best Regards, Fredrik
>> ------------------------------------------------------------------------
>> *From:* Yao Qi <>
>> *Sent:* Tuesday, September 27, 2016 3:38 AM
>> *To:* Adam Renquinha
>> *Cc:* Fredrik Hederstierna;
>> *Subject:* Re: [PATCH] Fix exception unwinding for ARM Cortex-M
>> On Mon, Sep 26, 2016 at 3:26 PM, Adam Renquinha <> wrote:
>>> That looks correct.
>> Patch is pushed into master and 7.12.  The rest of your original
>> patch is still welcome!
>> -- 
>> Yao (齐尧)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]