Re: [libc patch] __tls_get_addr with link_map * instead of modid

[Pedro Alves <palves@redhat.com>]

On 10/24/2014 03:22 PM, Carlos O'Donell wrote:
> I don't understand the tradeoffs, but if calling dlopen() in the inferior would
> have made life easy, then I would have done that first, regardless of the impact
> on the inferior. Only if users complained or found use cases where things broke
> would I have fallen back on the "technical purist" solution involving doing
> everything yourself. Those are decisions that you, as a gdb developer need to
> make, or reevaluate and make different.

Off the top of my head, I'm sure there are more:

- The user might want to evaluate an expression while the program itself
  has just called dlopen and is now stopped inside it.  This pesky dlopen
  recursion thing.  ;-)  It's best if GDB only calls async-signal
  safe functions behind the scenes, if possible.  Of course if the
  injected expression involves calls to async-signal unsafe code that breaks
  the inferior, the user gets what she asked for.

- The program might have not been linked with -ldl.

- I suspect there may be issues with messing with symbol resolution
  and self library walks in the inferior too.  Not sure if RTLD_LOCAL is
  enough.  dlmopen might be a better fit, but hmm, that isn't very
  well supported in GDB/glibc.

- A lower level mechanism has much better changes of working on
  more targets and runtimes of languages other than C with minimal
  changes.

Thanks,
Pedro Alves