From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
To: "'Tom Tromey'" <tromey@redhat.com>
Cc: <gdb-patches@sourceware.org>
Subject: RE: [RFC] pascal: also handle Free Pascal longjump function.
Date: Mon, 16 Dec 2013 23:12:00 -0000 [thread overview]
Message-ID: <00d101cefab4$347170b0$9d545210$@muller@ics-cnrs.unistra.fr> (raw)
In-Reply-To: <87mwk0pix6.fsf@fleche.redhat.com>
> -----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
next prev parent reply other threads:[~2013-12-16 23:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <37888.8297280811$1386971648@news.gmane.org>
2013-12-16 21:48 ` Tom Tromey
2013-12-16 23:12 ` Pierre Muller [this message]
[not found] ` <5512.41819416663$1387235536@news.gmane.org>
2013-12-18 15:02 ` Tom Tromey
2013-12-13 21:53 Pierre Muller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00d101cefab4$347170b0$9d545210$@muller@ics-cnrs.unistra.fr' \
--to=pierre.muller@ics-cnrs.unistra.fr \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox