Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support inlined function lookup #192

Closed
danielocfb opened this issue May 31, 2023 · 1 comment · Fixed by #336
Closed

Support inlined function lookup #192

danielocfb opened this issue May 31, 2023 · 1 comment · Fixed by #336
Assignees
Labels
enhancement New feature or request

Comments

@danielocfb
Copy link
Collaborator

We should support symbolization of inlined functions, information of which may be contained in DWARF from what I gather.

@danielocfb danielocfb added the enhancement New feature or request label Jun 7, 2023
@danielocfb danielocfb self-assigned this Jun 14, 2023
@danielocfb
Copy link
Collaborator Author

This also pertains the gsym functionality. The format supports inlined function symbolization, but currently we don't support consuming this information.

danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 20, 2023
This change adds the necessary bits for parsing and reporting inlined
function information to the Gsym resolver. Note that while the Gsym
resolver now is able to parse and report this information, the
user-facing Symbolizer cannot yet package it up for consumption by
clients.

Refs: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 20, 2023
Now that we have plumbed through all necessary bits and pieces for
reporting inlined function information, this change takes the logical
last step and adjusts the Sym type to contain inlined function
information as well.
We opted in favor of including this information into the Sym type
instead of creating fully blown Sym objects, to more closely track how
the various supported formats treat inlined function information and to
make it possible to have a 1:1 mapping between input address and output
Sym.

Refs: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 20, 2023
This change adds the necessary bits for parsing and reporting inlined
function information to the Gsym resolver. Note that while the Gsym
resolver now is able to parse and report this information, the
user-facing Symbolizer cannot yet package it up for consumption by
clients.

Refs: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 20, 2023
Now that we have plumbed through all necessary bits and pieces for
reporting inlined function information, this change takes the logical
last step and adjusts the Sym type to contain inlined function
information as well.
We opted in favor of including this information into the Sym type
instead of creating fully blown Sym objects, to more closely track how
the various supported formats treat inlined function information and to
make it possible to have a 1:1 mapping between input address and output
Sym.

Refs: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 20, 2023
This change adds the necessary bits for parsing and reporting inlined
function information to the Gsym resolver. Note that while the Gsym
resolver now is able to parse and report this information, the
user-facing Symbolizer cannot yet package it up for consumption by
clients.

Refs: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 20, 2023
Now that we have plumbed through all necessary bits and pieces for
reporting inlined function information, this change takes the logical
last step and adjusts the Sym type to contain inlined function
information as well.
We opted in favor of including this information into the Sym type
instead of creating fully blown Sym objects, to more closely track how
the various supported formats treat inlined function information and to
make it possible to have a 1:1 mapping between input address and output
Sym.

Refs: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 21, 2023
This change adds the necessary bits for parsing and reporting inlined
function information to the Gsym resolver. Note that while the Gsym
resolver now is able to parse and report this information, the
user-facing Symbolizer cannot yet package it up for consumption by
clients.

Refs: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 21, 2023
Now that we have plumbed through all necessary bits and pieces for
reporting inlined function information, this change takes the logical
last step and adjusts the Sym type to contain inlined function
information as well.
We opted in favor of including this information into the Sym type
instead of creating fully blown Sym objects, to more closely track how
the various supported formats treat inlined function information and to
make it possible to have a 1:1 mapping between input address and output
Sym.

Refs: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 21, 2023
This change adds the necessary bits for parsing and reporting inlined
function information to the Gsym resolver. Note that while the Gsym
resolver now is able to parse and report this information, the
user-facing Symbolizer cannot yet package it up for consumption by
clients.

Refs: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 21, 2023
Now that we have plumbed through all necessary bits and pieces for
reporting inlined function information, this change takes the logical
last step and adjusts the Sym type to contain inlined function
information as well.
We opted in favor of including this information into the Sym type
instead of creating fully blown Sym objects, to more closely track how
the various supported formats treat inlined function information and to
make it possible to have a 1:1 mapping between input address and output
Sym.

Refs: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 22, 2023
This change adds the necessary bits for parsing and reporting inlined
function information to the Gsym resolver. Note that while the Gsym
resolver now is able to parse and report this information, the
user-facing Symbolizer cannot yet package it up for consumption by
clients.

Refs: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 22, 2023
Now that we have plumbed through all necessary bits and pieces for
reporting inlined function information, this change takes the logical
last step and adjusts the Sym type to contain inlined function
information as well.
We opted in favor of including this information into the Sym type
instead of creating fully blown Sym objects, to more closely track how
the various supported formats treat inlined function information and to
make it possible to have a 1:1 mapping between input address and output
Sym.

Refs: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit that referenced this issue Sep 22, 2023
This change adds the necessary bits for parsing and reporting inlined
function information to the Gsym resolver. Note that while the Gsym
resolver now is able to parse and report this information, the
user-facing Symbolizer cannot yet package it up for consumption by
clients.

Refs: #192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit that referenced this issue Sep 22, 2023
Now that we have plumbed through all necessary bits and pieces for
reporting inlined function information, this change takes the logical
last step and adjusts the Sym type to contain inlined function
information as well.
We opted in favor of including this information into the Sym type
instead of creating fully blown Sym objects, to more closely track how
the various supported formats treat inlined function information and to
make it possible to have a 1:1 mapping between input address and output
Sym.

Refs: #192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 26, 2023
This change adds the necessary logic for decoding inlined functions when
using the DWARF format. Like the rest of the code in the module, it's
heavily based on the corresponding addr2line functionality.

Closes: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 26, 2023
This change adds the necessary logic for decoding inlined functions when
using the DWARF format. Like the rest of the code in the module, it's
heavily based on the corresponding addr2line functionality.

Closes: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 27, 2023
This change adds the necessary logic for decoding inlined functions when
using the DWARF format. Like the rest of the code in the module, it's
heavily based on the corresponding addr2line functionality.

Closes: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
danielocfb pushed a commit to danielocfb/blazesym that referenced this issue Sep 27, 2023
This change adds the necessary logic for decoding inlined functions when
using the DWARF format. Like the rest of the code in the module, it's
heavily based on the corresponding addr2line functionality.

Closes: libbpf#192

Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o added a commit that referenced this issue Sep 27, 2023
This change adds the necessary logic for decoding inlined functions when
using the DWARF format. Like the rest of the code in the module, it's
heavily based on the corresponding addr2line functionality.

Closes: #192

Signed-off-by: Daniel Müller <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant