[Lldb-commits] [lldb] [LLDB] Serve unknown type symbols through `qSymbol` (PR #200134)

[Aurore Poirier via lldb-commits]

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