Bug 13320 - Please support thumb entry points in PLT instead of using (more or less randomly located) stubs
Summary: Please support thumb entry points in PLT instead of using (more or less rando...
Status: NEW
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: 2.24
: P2 normal
Target Milestone: ---
Assignee: Doug Kwan
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-19 16:18 UTC by Mike Hommey
Modified: 2014-05-28 19:45 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
working patch, no incremental linker support (4.26 KB, patch)
2011-12-02 19:03 UTC, Nathan Froyd
Details | Diff
working patch, no incremental linker support (4.27 KB, patch)
2012-03-12 14:37 UTC, Nathan Froyd
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Hommey 2011-10-19 16:18:33 UTC
My original problem is the following:

I've been trying to pack hot startup functions in Firefox Android builds, which are essentially Thumb. The PLT entries that gold generates are however ARM, and jumping from the Firefox code to PLT entries requires stubs that do the interwork.

Unfortunately, these are anonymous (no corresponding symbol in the .text section), which makes it non-obvious where they come from (I should probably file a separate bug for that), and more importantly, they are located are arbitrary places, which clashes with packing hot startup functions.

However, GNU ld doesn't generate such stubs, and in fact has PLT entries that start as Thumb, and switch to ARM. They are basically 4 bytes longer than the PLT entries gold generates, but on the other hand, they save 12 bytes from the corresponding stub. This is what the GNU ld PLT entries look like:

278:	4778      	bx	pc
27a:	46c0      	nop			; (mov r8, r8)
27c:	e28fc600 	add	ip, pc, #0
280:	e28cca08 	add	ip, ip, #32768	; 0x8000
284:	e5bcf0b4 	ldr	pc, [ip, #180]!	; 0xb4

The ARM part is just the same as the one gold generates.
Comment 1 Mike Hommey 2011-10-26 11:41:22 UTC
BTW, it should be possible, in binaries that are completely compiled as thumb, to have a completely thumb PLT code.
Comment 2 Nathan Froyd 2011-12-02 19:03:11 UTC
Created attachment 6087 [details]
working patch, no incremental linker support

Here's a patch that gets things going; it works on several testcases I've tried.  I haven't run the test suite yet due to native testing requirements yet, but I have tested a wide range of branch distances and such and things look pretty good.

I'm also fairly certain this breaks when doing incremental linking.  Stubs are now variable-sized when using this scheme, and the incremental linking support is not yet (ever?) ready to handle that.  Making all stubs 16 bytes when using the incremental linking support is a possibility.
Comment 3 Doug Kwan 2011-12-02 19:23:56 UTC
Thanks for working on this.  You can run the test suite using QEMU, it
is slow but it does the job.  You do need to treat one of test case
because it has too many sections that gold runs out of simulated
memory.  One caveat is that QEMU does not catch unaligned accesses, we
had bugs due to unaligned accesses in the past.  Incremental linking
never works on ARM, BTW.

I will take a look at your patch.

-Doug

On Fri, Dec 2, 2011 at 11:03 AM, froydnj at gmail dot com
<sourceware-bugzilla@sourceware.org> wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=13320
>
> --- Comment #2 from Nathan Froyd <froydnj at gmail dot com> 2011-12-02 19:03:11 UTC ---
> Created attachment 6087 [details]
>  --> http://sourceware.org/bugzilla/attachment.cgi?id=6087
> working patch, no incremental linker support
>
> Here's a patch that gets things going; it works on several testcases I've
> tried.  I haven't run the test suite yet due to native testing requirements
> yet, but I have tested a wide range of branch distances and such and things
> look pretty good.
>
> I'm also fairly certain this breaks when doing incremental linking.  Stubs are
> now variable-sized when using this scheme, and the incremental linking support
> is not yet (ever?) ready to handle that.  Making all stubs 16 bytes when using
> the incremental linking support is a possibility.
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
Comment 4 Nathan Froyd 2011-12-02 20:14:50 UTC
I was trying to set things up inside a QEMU VM, but was running into problems because Debian 5.0 uses deprecated relocations that gold does not support.  What distribution are you using?  Or do you have clever hacks that enable running the testsuite with the QEMU linux-user support?
Comment 5 Doug Kwan 2011-12-02 20:42:21 UTC
ubuntu karmic.  I wish I could use QEMU linux-user but I right now I
had to use the system emulator.

On Fri, Dec 2, 2011 at 12:14 PM, froydnj at gmail dot com
<sourceware-bugzilla@sourceware.org> wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=13320
>
> Nathan Froyd <froydnj at gmail dot com> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |froydnj at gmail dot com
>
> --- Comment #4 from Nathan Froyd <froydnj at gmail dot com> 2011-12-02 20:14:50 UTC ---
> I was trying to set things up inside a QEMU VM, but was running into problems
> because Debian 5.0 uses deprecated relocations that gold does not support.
> What distribution are you using?  Or do you have clever hacks that enable
> running the testsuite with the QEMU linux-user support?
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
Comment 6 Nathan Froyd 2012-03-12 14:37:28 UTC
Created attachment 6284 [details]
working patch, no incremental linker support

Rebase against current HEAD.
Comment 7 Khem Raj 2012-05-10 01:20:12 UTC
(In reply to comment #6)
> Created attachment 6284 [details]
> working patch, no incremental linker support
> 
> Rebase against current HEAD.

This fails when you link pre-armv5 thumb binaries. e.g. armv4t
Comment 8 Jackie Rosen 2014-02-16 17:46:42 UTC Comment hidden (spam)