[Bug gdb/34367] New: GDB internal inferior malloc lookup may call GNU IFUNC resolver directly

https://sourceware.org/bugzilla/show_bug.cgi?id=34367

            Bug ID: 34367
           Summary: GDB internal inferior malloc lookup may call GNU IFUNC
                    resolver directly
           Product: gdb
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: muhammad.kamran at arm dot com
  Target Milestone: ---

GDB uses value_allocate_space_in_inferior to allocate temporary inferior
memory,
for example when copying string literal arguments into the inferior. This path
finds malloc with find_function_in_inferior("malloc") and then calls it with
call_function_by_hand.

If malloc is a GNU IFUNC and only minimal-symbol information is available, GDB
can end up treating the minimal-symbol/resolver path as directly callable. This
is problematic because an IFUNC must be resolved before corresponding function
can be called as such.

A proposed direction is to avoid direct IFUNC resolver calls for this internal
malloc lookup by resolving malloc through inferior dlsym when possible. The
dlsym path has a bootstrapping issue: passing the string "malloc" as a normal
GDB string value would itself require value_allocate_space_in_inferior, causing
recursion. The string argument can instead be placed in temporary inferior
stack
storage associated with the dummy call frame, and dlsym can receive a plain
char * pointer to that stack storage.

The lookup order could be:

1. Use non-intrusive GDB-side lookup when it yields a normal callable function.
2. If the internal malloc symbol is an IFUNC, try inferior dlsym("malloc"),
   passing the symbol-name string via temporary dummy-frame stack storage.
3. If dlsym is unavailable or fails, decide whether to fall back to the
existing
   minimal-symbol/IFUNC-resolver behavior or fail cleanly, depending on the
   agreed policy for direct resolver calls.

Open concerns:

- Calling inferior dlsym can block if the inferior is stopped while another
  thread holds dynamic-loader/libc locks. This is part of the general inferior
  call caveat, but it should be considered when deciding whether dlsym failure
  may fall back or must fail.
- dlsym itself must not be resolved via the dlsym path; it needs a bootstrap
  lookup path.
- Targets without a useful dlsym (i.e. static programs, non-ELF targets etc.)
need
  defined behavior.
- The stack string has only call-duration lifetime, which should be suitable
for
  dlsym's symbol-name argument.

-- 
You are receiving this mail because:
You are on the CC list for the bug.