> I dropped the arm32 frame pointer unwinder for now (maybe we need a less
> demanding testcase for that or, more awesome, add code to translate the
> exidx section for that).
Another problem is that QV4-generated code on a new frame pushes LR first and
then FP. Code generated by gcc with "-arm -
On Tue, 2017-04-25 at 15:38 +0200, Ulf Hermann wrote:
> > My question is about this "initial frame". In our testcase we don't have
> > this case since the backtrace starts in a function that has some CFI.
> > But I assume you have some tests that rely on this behavior.
>
> Actually the test I prov
On Fri, 2017-04-21 at 18:51 +0200, Ulf Hermann wrote:
> + * .gitignore: Add fillfile and peel_type tests.
Pushed to master.
Thanks,
Mark
On Thu, 2017-04-20 at 17:07 +0200, Ulf Hermann wrote:
> BYTE_ORDER and friends are customarily defined in endian.h.
Right. Which we do in all other places where BYTE_ORDER is used.
Pushed to master.
Thanks,
Mark
On Thu, 2017-04-20 at 17:02 +0200, Ulf Hermann wrote:
> Otherwise the build will fail on systems that actually need file
> extension for executables.
Thanks, pushed to master.
We seem to add it in other cases. Surprising this seems to be the only
case that got forgotten. I would have expected more
On 04/26/2017 04:33 PM, Mark Wielaard wrote:
> On Tue, 2017-04-25 at 15:38 +0200, Ulf Hermann wrote:
>>> My question is about this "initial frame". In our testcase we don't have
>>> this case since the backtrace starts in a function that has some CFI.
>>> But I assume you have some tests that rely
On Wed, 2017-04-26 at 17:27 +0200, Ulf Hermann wrote:
> However, if you strip .eh_frame and .eh_frame_hdr from the exe (thus
> triggering the fp unwinding on the first frame), you will see that it
> skips sigusr2. At the same time it invents another frame 0x403f40 on
> the main thread. Apparently p
