[llvm-bugs] [Bug 45698] New: Handle out-of-order PT_LOADs better

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45698

            Bug ID: 45698
           Summary: Handle out-of-order PT_LOADs better
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llvm-readobj
          Assignee: unassignedbugs at nondot.org
          Reporter: jh7370.2008 at my.bristol.ac.uk
                CC: jh7370.2008 at my.bristol.ac.uk, llvm-bugs at lists.llvm.org

The gABI requires loadable segments to be in ascending address order. The LLVM
Object library relies on this when looking up addresses (see "toMappedAddr",
specifically the std::upper_bound call for at least one example). If the order
is wrong, it can result in "virtual address is not in any segment" warnings,
which is confusing and not strictly correct, but rather is the result of the
std::upper_bound call not working well for unsorted program headers.

We have two options:
1) Sort the program headers up front before the lookup mentioned in the
example. This would solve the issue in this one place, but there may well be
various others which this doesn't handle.
2) Add a warning if the program headers are out-of-order in the tool. This
should be more clearly understandable than the current warning, and would
hopefully stop people relying on out-of-order segments.

One of our users recently ran into some confusion because of this after using a
linker script which did something wrong. We might also want to consider adding
a warning to LLD for this situation - see bug 45697.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200427/0456d64e/attachment.html>