Temporary workaround for unsupported DWARF location types #626
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #626 +/- ##
===========================================
- Coverage 69.60% 40.98% -28.62%
===========================================
Files 92 89 -3
Lines 7633 7441 -192
===========================================
- Hits 5313 3050 -2263
- Misses 2068 4217 +2149
+ Partials 252 174 -78
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
Closing by now, as the original issue seems to come from a wrong language detection and not from a weird Go compilation. |
|
I think we need this :), can we continue with it? I think we can craft a unit test to expose this issue, I think since we give into inspecting ELF files, we'll hit this again. |
| } else { | ||
| // Temporary workaround | ||
| // TODO: properly address issue https://github.com/grafana/beyla/issues/625 | ||
| return fmt.Errorf("at the moment, Beyla only supports constant values for DW_AT_data_member_location;"+ |
There was a problem hiding this comment.
Do we want to use the logger for this?
There was a problem hiding this comment.
it will be logged as debug from the code that receives the error.
|
I added a unit test with mocked data but once we fix the original issue (wrong language detection) I'll add an integration test with a real R executable. |
This is a temporary, first workaround to quickly unblock some non-working users.
As reported in issue #625, we are assuming that all the variable offsets are stored as a constant. According to DWARF specification (page 227) this value can also be an exprloc or a loclist.
Since completely supporting the DWARF spec might take some extra time to address and support, by now we will fallback to the preloaded offsets database when we find a non-constant location.