Assertion Fail: FDE != NULL in Cyclops64

Assertion Fail: FDE != NULL in Cyclops64

[Brian Heilig]

Dear list,

I am receiving an assertion violation, "fde != NULL" on my Cyclops64
system. This occurs in the function "dwarf2_frame" in "dwarf2_frame.c"
while attempting to single step through memmove.

I found that memmove (and other functions) were not compiled with debug
information. Since these were hand optimized routines in assembly it
would be very difficult to add debugging information.

On a plain Linux test I get "Single stepping until exit from function
foo, which has no line number information." That's what my Cyclops64
system should do.

When I perform a readelf on my Cyclops64 executable there are holes in
the .debug_frame section where memmove (and the others) should be. It
looks like gdb assumes there are no holes, so I'm guessing the problem
is somewhere in my tool chain. Can someone direct me to the right spot?

I'm using gcc version 4.3.2, gdb 7.1.90, and GNU binutils 2.18, all
ported to Cyclops64.

Thanks,
Brian

Re: Assertion Fail: FDE != NULL in Cyclops64

[Tom Tromey]

>>>>> "Brian" == Brian Heilig <bheilig@etinternational.com> writes:

Brian> I am receiving an assertion violation, "fde != NULL" on my Cyclops64
Brian> system. This occurs in the function "dwarf2_frame" in "dwarf2_frame.c"
Brian> while attempting to single step through memmove.

Brian> I found that memmove (and other functions) were not compiled with debug
Brian> information. Since these were hand optimized routines in assembly it
Brian> would be very difficult to add debugging information.

Brian> On a plain Linux test I get "Single stepping until exit from function
Brian> foo, which has no line number information." That's what my Cyclops64
Brian> system should do.

Brian> When I perform a readelf on my Cyclops64 executable there are holes in
Brian> the .debug_frame section where memmove (and the others) should be. It
Brian> looks like gdb assumes there are no holes, so I'm guessing the problem
Brian> is somewhere in my tool chain. Can someone direct me to the right spot?

I am not overly familiar with this code, but I think the logic behind
this assert is that we should only end up in dwarf2_frame_cache if a
DWARF frame was detected, and the DWARF frame sniffers use
dwarf2_frame_find_fde to decide whether this happened.

In other words, if the assert trips then that means there is some kind
of bug in gdb -- because dwarf2_frame_find_fde returned different
results for the same PC.

I would probably start by putting a breakpoint in dwarf2_frame_sniffer
to see what happens there, or maybe by finding out where the frame comes
from in dwarf2_frame_cache.

Tom

Re: Assertion Fail: FDE != NULL in Cyclops64

[Petr Hluzín]

Hello

On 22 November 2010 16:16, Brian Heilig <bheilig@etinternational.com> wrote:
> I found that memmove (and other functions) were not compiled with debug
> information. Since these were hand optimized routines in assembly it
> would be very difficult to add debugging information.

What kind of debugging information to add?

Source lines? GAS has an option to include these. It has to be enabled
manually, GCC does not pass -g option for some reason.

Type information? I dunno.

Stack-trace/-unwind info? I think this should be easy. The feature is
well hidden in GAS. I fact it is not supported on some architectures
and the docs do not say which. (I got burnt.) If GAS implements them
then I might try to write the annotations for the memmove.

Where is the source for the memmove function?
Is it in-line assembly in C file or standalone asm file? (I assume standalone.)

(I know nothing about the assertion or its surrounding code.)

-- 
Petr Hluzin