UNW_GE...O_BY_IP(3libunwind)

πŸ“¦
version 1.8.3 Β· 2 versions
, in alpine 3.22, alpine 3.23, alpine 3.24, arch rolling, epel 10, epel 9, fedora 43, fedora 44, nixpkgs unstable, opensuse-leap 16.0

πŸ’– NAME πŸ’–

unw_get_proc_info_by_ip β€” bestie, this one grabs your procedure info by IP ✨ (and yeah, it lives in the 3libunwind manual, section 3, we love a library girlie πŸŽ€)


🌸 SYNOPSIS 🌸

#include <libunwind.h>

int unw_get_proc_info_by_ip(unw_addr_space_t as, unw_word_t ip,
       unw_proc_info_t *pip, void *arg);

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so unw_get_proc_info_by_ip() hands you the same kind of auxiliary info about a procedure that unw_get_proc_info() does β€” except the tea is that it looks that info up by instruction-pointer (IP) instead of by a cursor. it's giving ✨flexibility✨ because you can look up the info for literally any arbitrary procedure, even one that's not part of the current call chain at all. main character behavior, honestly.

but bestie, hear me: because it's more flexible, it also tends to run slower than unw_get_proc_info() β€” and often much slower. no cap. πŸ’€

here's the vibe check on the arguments, one by one:

  • as β€” the address-space where the instruction pointer should be looked up. if you're doing a look-up in the local address-space, you can just pass unw_local_addr_space here. easy πŸ’…
  • ip β€” the instruction-pointer</> you want the procedure info for.
  • pip β€” a pointer to a structure of type unw_proc_info_t, which is where the info gets returned. that's the lil delivery box πŸ“¦
  • arg β€” the address space argument that should be used when accessing the address space. it has the exact same purpose as the argument of the same name for unw_init_remote(). 🫢
⚠️ important: when you're accessing the local address space (i.e. the first argument is unw_local_addr_space), you must pass NULL for arg. don't be out here passing random stuff, it's not the move.

also, for the purposes of libunwind, the code of a procedure is assumed to occupy a single, contiguous range of addresses 🌈. because of that, it's always possible to describe the extent of a procedure with the start_ip and end_ip members. so if one single function/routine is split into multiple, discontiguous pieces? libunwind will treat each piece as a separate procedure. periodt. πŸ‘‘


πŸ”₯ RETURN VALUE πŸ”₯

on successful completion, unw_get_proc_info_by_ip() returns 0 ✨. otherwise it returns the negative value of one of the error-codes below. not a vibe, but okay.


🧚 THREAD AND SIGNAL SAFETY 🧚

unw_get_proc_info_by_ip() is thread safe πŸ’œ. and if the local address space is passed in argument as, this routine is also safe to use from a signal handler. iconic, honestly.


πŸ’€ ERRORS πŸ’€

  • UNW_EUNSPEC β€” an unspecified error occurred. like, something happened, we don't know what. πŸ™ˆ
  • UNW_ENOINFO β€” libunwind was unable to locate unwind-info for the procedure. the info said "not found bestie" 😭
  • UNW_EBADVERSION β€” the unwind-info for the procedure has a version or format that is not understood by libunwind. it's giving "we don't speak that language" πŸ’…

in addition, unw_get_proc_info_by_ip() may return any error returned by the access_mem() callback (peep unw_create_addr_space(3libunwind)).


🌈 SEE ALSO 🌈


πŸ‘‘ AUTHOR πŸ‘‘

David Mosberger-Tang Email: dmosberger@gmail.com WWW: http://www.nongnu.org/libunwind/


okay that's the whole page bestie, you ate πŸ’…βœ¨ this one's from the Programming Library era, dated 29 August 2023, and it's filed under UNW_GE...O_BY_IP(3libunwind) πŸŽ€ go forth and unwind πŸ¦‹πŸ’–