aurore-poirier wrote: > That looks like a mistake to me, I think it should be "if not MachO then > return values for more symbol types". Maybe I am misreading it but even so, > the intent is to change the behaviour of non-MachO targets (aka ELF).
It indeed is a mistake from swapping the blocks to un-nest most of the code. Fixing this (and python lint) and pushing. > please look into f0697d7c3fb5296cfec1718206aceb77b7ca9ab8 and see if the > symbols you have issues with are effected by it. I did not succeed at building f0697d7c3fb5296cfec1718206aceb77b7ca9ab8 so i can't be 100% sure, but reading the code (and `readelf` output from the minimal example), i guess that my symbols are affected by it (they are identified as ABS indexes and not in any particular section). AFAIK, nothing enforces an ELF symbol to be a valid address, that's more or less what `.set` assembly instructions are for, they can hold any arbitrary value. Nothing enforces `qSymbol` to return valid addresses either (and actually, GDB does not care if a symbol is valid, it just returns it). The main reason i added the change in `GDBRemoteCommunicationClient.cpp` is that it looks like that the `Symbol` class is meant to work with addresses, but i guess we can still move part of the logic in the symbol class, i just wanted to avoid touching it in case other places were always expecting valid addresses. > please copy your explanation of the problem into the PR description as well, > easier to find it there. Done https://github.com/llvm/llvm-project/pull/200134 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
