This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: linking problem - mips32 Android

On Mon, Aug 24, 2015 at 8:52 AM, Andrzej Warzynski <> wrote:
> Hello,
> We've recently came across a weird behavior with ld, and I wanted to
> check whether this is a known issue and what's the best way to solve it.
> We're using ld to link position independent binaries (passing the -pie
> flag) for mips32 devices running Android. The problem is that ld marks
> such binaries as shared when parsing arguments. This is implemented in
> the parse_args() function in the lexsup.c file:
> case OPTION_PIE:
>      if (config.has_shared)
>      {
>          link_info.shared = TRUE;
>          link_info.pie = TRUE;
>      }
> However, having been compiled with -pie does not necessarily imply that
> it is a shared object, it could be an executable. Indeed, Android
> requires all binaries to be position independent (i.e. linked with the
> -pie flag), both shared objects and executables.
> The above situation is particularly problematic for us, because it
> prevents the _bfd_mips_elf_size_dynamic_sections() function in the
> elfxx-mips.c file from adding the DT_MIPS_RLD_MAP structure to the
> .dynamic section. This is due to the following check on line 9786 in
> elfxx-mips.c (binutils-2.25.1):
> if (!info->shared && !MIPS_ELF_ADD_DYNAMIC_ENTRY (info, DT_MIPS_RLD_MAP,
> 0))
> This check means that DT_MIPS_RLD_MAP will not be added if the file
> that's being processed is flagged as shared. The DT_MIPS_RLD_MAP
> structure is used by debuggers to track loading and unloading of shared
> objects. The above behavior (i.e. flagging all position independent
> binaries as shared objects) renders debugging executables for mips32
> Android impossible.
> Is it necessary to flag all position independent executables as shared?
> There's a bunch of easy workarounds, but we're not really sure what
> would be the optimal solution.

Please checkout master branch.  It has been changed.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]