On 02/05/2015 03:44 PM, Petr Machata wrote:
> Faraz Shahbazker <[email protected]> writes:
>
>> To capture the last one, I've added a check for whether proc->pid occurs
>> in options.h:opt_p - not sure if there is a simpler way of performing
>> this check.
>
> Both a -p and a command can be given. Probably not something that would
> typically be used, but nonetheless this is not a correct way to check
> for this.
>
> arch_dylink_done is called either for a process whose execution ltrace
> has under control (i.e. initial process or forks of already traced
> processes), or always for a process that we attach to. In theory it can
> be called even though arch_dylink_ was not, in fact, _done, there's no
> deep logic in ltrace to figure out whether the dynamic linker actually
> did finish doing its thing.
>
> Which is a shame, but still you could use the callback to make a mark
> somewhere and later check it. Or create breakpoins as delayed and only
> activate them in the callback--that's what PPC does.
It seems like there is no easy way to determine whether GOT entries are biased
or not before arch_dynlink_done is called, which makes it impossible to
determine if a symbol is resolved or unresolved when creating the plt entry.
How about if we create all those fake plt entries as UNRESOLVED(+delayed)
initially and determine otherwise only in arch_symlink_done? This avoids my
absurd conditional bias logic.
arch_elf_add_plt_entry(...)
{
...
/* All symbols unconditionally unresolved at this point */
libsym->arch.type = MIPS_PLT_UNRESOLVED;
libsym->arch.resolved_value = stub_addr + bias;
libsym->arch.got_entry_addr = got_entry_addr + bias;
libsym->arch.delayed = 1;
...
}
arch_dynlink_done(struct process *proc)
{
for (libsym in <each delayed symbol>) {
read_got_entry(proc, libsym->arch.got_entry_addr,
&got_entry_value);
if (got_entry_value != libsym->arch.resolved_value) {
/* Symbol is resolved, mark it as NEED_UNRESOLVE and create
unresolve_data */
...
}
activate_delayed_symbol();
}
}
Regards,
Faraz Shahbazker
_______________________________________________
Ltrace-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
