The SymbolData function in libpf/pfelf/file.go accepts a maxCopy argument that is intended to limit the amount of data read when the underlying implementation is not backed by mmap.

However, this parameter may be misleading because it is almost always ineffective: The maxCopy argument is only used when the underlying elfReader is NOT a *mmap.ReaderAt.

In practice, most ELF files are memory-mapped, making this parameter irrelevant in the vast majority of cases. In practice the whole mmaped symbol data returned.

An example of this issue could be :

• this conversation during code review in PR #552 where concerns were raised about using math.MaxInt64 and the need for realistic size caps, but the fundamental issue of the parameter being ineffective in most cases wasn't fully addressed.
• ef.SymbolData(symbolName, 64) - interpreter/python/python.go:658
• ef.SymbolData("execute_ex", 128) - interpreter/php/php.go:205

When mmapped implementation is NOT used

• Test cases: When using NewFile() with a non-mmap reader
• Coredumps: When processing core dump files

Possible improvements

1. Update documentation: Add a more explicit warning that users of the ef.SymbolData should truncate data if needed

2. Always truncate data: Modify the SymbolData function to always respect the maxCopy limit regardless of the underlying implementation (mmap or not), ensuring consistent behavior.

3. Truncate the data at the caller: Modify the callers to truncate the returned from SymbolData