[Lldb-commits] [PATCH] D158583: Fix shared library loading when users define duplicate _r_debug structure.

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

In D158583#4627644 <https://reviews.llvm.org/D158583#4627644>, @DavidSpickett wrote:

> The added context helps document what was already there so that's a nice improvement.
>
> Something I'm not clear on mechanically. The original r_debug has eAdd set. Then the second r_debug is loaded, which also has eAdd set. What is the state of r_map at that point? I wonder if it could be somehow different between the 2 copies, with each having a subset of the list.

Once we stop at the breakpoint the second time, second r_debug has eConsistent set when the original has eAdd, but we only look at the original r_debug in the ld.so binary.

Actually the _only_ thing the "_r_debug" in the main executable has set is the "r_state" when we stop at the second breakpoint, the r_map is set correctly in the ld.so version, but not in the a.out version. If you continue to run, the a.out version does eventually get updated. It just depends when the ld.so writes new things into the new r_debug struct.

I actually ran a test where I created a global variable with the same name but different type:

  char _r_debug[40] = "012345678901234567890123456789012345678"; // Same size as "r_debug" for safety

And then ran the program to the entry point and the "r_state" bytes in the above character array had been written to zero, but nothing else was touched. So I know this definitely isn't meant to happen.

The ld.so's "_r_debug.r_map" is correct and has a linked list of all the current libraries. But it really depends on when the _r_debug struct is written to again by ld.so.

> Also, why do we not have to wait for eConsistent on the second r_debug?

Because the first eAdd state indicates the ld.so is _about_ to load the shared libraries. So debuggers can't actually set breakpoints in them until all of the shared libraries are actually loaded.

> Is it that we do in fact wait for that, but we load the library list from the first r_debug, then when the second one gets eConsistent, we load the rest from that.

It is because when we receive the eConsistent the libraries are actually now loaded into memory and then we can load the libraries in LLDB and can actually resolve any breakpoints since the .text sections are now mapped and we can write breakpoints into their .text sections.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158583/new/

https://reviews.llvm.org/D158583