Hello everybody,

I'm working on a wrapper of a C library. I've found a bug, but I can't debug it with GDB because if I compile with "-g" and link with the debug version of the library it works correctly.

But if I compile with "-g" and link with the release version of the library, I can't debug it because it fails inside the library. So I suspect there's a problem with a data conversion CPU exception activated by FPC.

What can I do?

Guillermo "Ñuño" Martínez

Can you give any more information about how it fails? You may have to set the fpu exception mask if you're talking to c code, as a quick guess (search the archives for how). Don't know why this works with debugging enabled, though.

Henry

e.g.

  {$if defined(cpui386) or defined(cpux86_64)}
    SetExceptionMask(GetExceptionMask + [exZeroDivide, exInvalidOp]);
  {$ifend}

Thanks, Henry,

Can you give any more information about how it fails?

It's a "SIGSEGV". The library is the Allegro library version 5.0.6.

The error is inside an internal procedure that uploads a texture to OpenGL context, and it is used by other Allegro functions (i.e. loading pictures from file, building text fonts, etc.).

Initially I suspected that I didn't use the right data types, but after revisiting and fixing some of them it I'm pretty sure I'm using the right ones.

I don't know what can I say. :-/

You may have to set the fpu exception mask if you're talking to c code, as a quick guess (search the archives for how). Don't know why this works with debugging enabled, though.

I've revise the command-line options list and the only one I've find is that:

-Cf<x> Select fpu instruction set to use, see fpc -i for possible values

I don't know how can it help. :-?

Regards,
Guillermo Martínez

It's hard to say without seeing your function/type declarations.

Henry

From: Henry Vermaak Subject: Re: [fpc-pascal] Re: Runs correctly when debugging. It's hard to say without seeing your function/type declarations.

Actually I don't call the function that raises the SIGSEGV signal, since it's an internal function. Allegro has a "driver" struct (RECORD) that stores a pointer to this function only if OpenGL is used (else it uses DirectX or something like that), then functions that uses or modifies the "bitmap" struct uses it.

For example, it's used by next function:

  ALLEGRO_BITMAP *al_load_bitmap(const char *filename);

The wrapper I wrote is:

  TYPE
  (* Abstract type representing a bitmap (2D image). *)
    ALLEGRO_BITMAPptr = POINTER;
  FUNCTION al_load_bitmap (CONST filename: STRING): ALLEGRO_BITMAPptr; CDECL;
  EXTERNAL ALLEGRO_LIB_NAME;

I'm concerning about the "STRING" type as it may affect the stack (I had problems with enumerations because FPC optimised them and C doesn't) and use "PCHAR" instead, but manual says it's not a problem if using "-h" or "{$LONGSTRINGS ON}".

No, you have to use pchar. I would also define ALLEGRO_BITMAP as an empty record, to be clear that it's an opaque type:

{$packrecords c}
  TAllegroBitmap = record
  end;
  PAllegroBitmap = ^TAllegroBitmap;

Thus:

function al_load_bitmap(const filename: pchar): PAllegroBitmap; cdecl;
external ALLEGRO_LIB_NAME;

Make sure you use {$packrecords c}. Use the types in unit "ctypes", e.g. cint, cfloat, cdouble. This will ensure the variables are the same size and work on all architectures.

Henry

Ok, then I should revise all the "STRING" parameters, as well as all pointer types and "ctypes".

Thanks for the advices.
Guillermo.