Re: [RFC] pascal: also handle Free Pascal longjump function.

Re: [RFC] pascal: also handle Free Pascal longjump function.

[Tom Tromey]

>>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes:

Pierre> - Where is this internal long jump breakpoint really used in the code?

Search infrun.c for BPSTAT_WHAT_SET_LONGJMP_RESUME.

Pierre> - Is this kind of patch likely to be accepted?

Sure.

Pierre> I would perfectly understand that it would be not acceptable as is,
Pierre> but maybe some language specific version of the
Pierre> longjmp name would be useful, no?

I don't think it makes sense to be language-dependent here, because
then this makes mixed-language debugging harder.

I do wonder whether gdb will really be able to understand this function.
Does it make jmp_bufs compatible with the arch support already in gdb?
What about PC mangling?  What defines fpc_longjmp and why is it not just
a simple wrapper for the C library longjmp?

Tom

RE: [RFC] pascal: also handle Free Pascal longjump function.

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Tom Tromey
> Envoyé : lundi 16 décembre 2013 22:48
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org
> Objet : Re: [RFC] pascal: also handle Free Pascal longjump function.
> 
> >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
> writes:
> 
> Pierre> - Where is this internal long jump breakpoint really used in
> the code?
> 
> Search infrun.c for BPSTAT_WHAT_SET_LONGJMP_RESUME.
  Thanks for the information. 
> Pierre> - Is this kind of patch likely to be accepted?
> 
> Sure.
OK, great!
 
> Pierre> I would perfectly understand that it would be not acceptable as
> is,
> Pierre> but maybe some language specific version of the
> Pierre> longjmp name would be useful, no?
> 
> I don't think it makes sense to be language-dependent here, because
> then this makes mixed-language debugging harder.
> 
> I do wonder whether gdb will really be able to understand this function.
> Does it make jmp_bufs compatible with the arch support already in gdb?

  I checked the i386 case, which seems indeed quite bad:
1) the fpc_setjmp fpc_longjmp function seem to use the register call ABI...
  So the jump buffer is passed in register eax.
By the way, did Jonas Maebe attempt to add i386 register call convention
to dwarf standard complete?
 
2) the jump buffer is much smaller than the cygwin case for instance...
The buffer only saves the registers that are preserved on function calls
according to that ABI, i.e. ebx, esi and edi, the stack registers esp and
ebp
and the return pc address.
  This put the return address at offset 20 inside the jump buffer.

  I suspect that it would at least require some init_abi function
to set this... But then the question is, how do we recognize 
such executables...

> What about PC mangling? 
  I am not sure what you mean here...
There is no operation on pc value.
> What defines fpc_longjmp
  It is defined in the Free Pascal RTL (Run Time Library)
which can be considered as a pascal base library.
  It is used internally by the compiler to generate the long jumps.
> and why is it not just
> a simple wrapper for the C library longjmp?

Because, by default, Free Pascal compiler generates code that is
independent of any library (static code on Linux for instance)
with only direct calls to System Calls.


Pierre

Re: [RFC] pascal: also handle Free Pascal longjump function.

[Tom Tromey]

>>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes:

Pierre>   I suspect that it would at least require some init_abi function
Pierre> to set this... But then the question is, how do we recognize 
Pierre> such executables...

You'll at least need different code to extract the target PC from the
jump buffer.

Tom> What about PC mangling? 

Pierre>   I am not sure what you mean here...
Pierre> There is no operation on pc value.

On some platforms glibc mangles the PC value that is saved in the
buffer.

Tom> and why is it not just
Tom> a simple wrapper for the C library longjmp?

Pierre> Because, by default, Free Pascal compiler generates code that is
Pierre> independent of any library (static code on Linux for instance)
Pierre> with only direct calls to System Calls.

Makes sense.  I guess some deeper change is needed, not just adding
fpc_longjmp to the list.

Tom

[RFC] pascal: also handle Free Pascal longjump function.

[Pierre Muller]

  Free pascal uses fpc_longjmp internal name
for the long jump function.

  I would like to know two things:

- Where is this internal long jump breakpoint really used in the code?
- Is this kind of patch likely to be accepted?
I would perfectly understand that it would be not acceptable as is,
but maybe some language specific version of the
longjmp name would be useful, no?

  Comments most welcome.

Pierre Muller


ChangeLog entry:

2013-12-13  Pierre Muller  <muller@sourceware.org>

      Also accept Free Pascal name for longjmp function.

--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -3086,7 +3086,7 @@ create_internal_breakpoint (struct gdbarch *gdbarch,

 static const char *const longjmp_names[] =
   {
-    "longjmp", "_longjmp", "siglongjmp", "_siglongjmp"
+    "longjmp", "_longjmp", "siglongjmp", "_siglongjmp", "fpc_longjmp"
   };
 #define NUM_LONGJMP_NAMES ARRAY_SIZE(longjmp_names)