This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Java stack trace vs. the PLT
- From: Richard Henderson <rth at redhat dot com>
- To: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- Cc: gcc at gcc dot gnu dot org, Java <java at gcc dot gnu dot org>
- Date: Mon, 3 Nov 2003 00:06:59 -0800
- Subject: Re: Java stack trace vs. the PLT
- References: <CF78512A-0DAA-11D8-AFD5-003065F97F7C@mckinlay.net.nz>
On Mon, Nov 03, 2003 at 04:07:08PM +1300, Bryce McKinlay wrote:
> struct _Jv_Method
> {
> _Jv_Utf8Const *name;
> _Jv_Utf8Const *signature;
> _Jv_ushort accflags;
> _Jv_ushort index;
> void *ncode;
> _Jv_Utf8Const **throws;
> }
...
> Is there anything we can do to ensure that ncode always gets resolved
> by the linker to the actual address of the function, and not a PLT
> indirection?
Actually, if this structure is built in the same object file as the
function, then the solution is to use a local label for the address.
See e.g. make_alias_for_thunk in the c++ front end. We can move this
somewhere else if you need...
r~