[Lldb-commits] [PATCH] Fetch object file load address if it isn't specified by the linker

Tamas Berghammer tberghammer at google.com
Wed Jun 17 14:25:37 PDT 2015

Comment at: docs/lldb-gdb-remote.txt:999
@@ +998,3 @@
+//  <unsinged-hex64>: The load address of the file
+//  "FFFFFFFFFFFFFFFF": ((uint64_t)(-1)) The requested file isn't loaded
labath wrote:
> What is going to be the endianness of this value? I propose big endian, as that is what most packets seem to be using.
Clarified documentation (big endian)

Comment at: docs/lldb-gdb-remote.txt:1001
@@ +1000,3 @@
+//  "FFFFFFFFFFFFFFFF": ((uint64_t)(-1)) The requested file isn't loaded
+//  "EXX" - for any errors
aidan.dodds wrote:
> labath wrote:
> > I know F..F is not likely to be a valid load address, but what do you think about using one of the error codes to signify this condition? If it is not too much of a trouble to implement it, it sounds like a more reasonable solution.
> An error code sounds good to me too as its less ambigous.
(Use "E01" for file not loaded error.)

Comment at: include/lldb/Target/Process.h:3049
@@ +3048,3 @@
+    ///     The load address of the file if it is loaded into the
+    ///     processes address space. LLDB_INAVLID_ADDRESS if the file
+    ///     isn't loaded.
labath wrote:

Comment at: source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp:415
@@ +414,3 @@
+    if (entry.base_addr == 0)
+    {
+        lldb::addr_t load_addr = LLDB_INVALID_ADDRESS;
aidan.dodds wrote:
> On some targets 0 can be a valid load address (Hexagon for example).  I dont think this will cause problems in that case, as the call to GetFileLoadAddress() should return 0 in that case.  But if your changing this peice of code it may be good to keep in mind.
Thanks for the information. I believe this change won't cause any issue on hexagon but it is good to know.



More information about the lldb-commits mailing list