[lldb-dev] question about link_map data structure in elf on 64-bit Linux systems

[Steve Pucci]

> If it's not readily available, I guess I could just use the size of a
pointer on the target?

Or somewhat safer (but hackier), we could just continue to read 32 bits on
little-endian machines and read pointer-sized ints on big-endian targets.



On Mon, Feb 3, 2014 at 8:31 AM, Steve Pucci <spucci at google.com> wrote:

> Hi Richard,
>
> I'm looking at this now.  I'm having trouble finding the symbol name I
> need to query to get the modid size in DYLDRendezvous::GetThreadInfo().  Is
> there a document somewhere that describes those symbols (like
> _thread_db_link_map_l_tls_modid)?  I'm not finding them with Google.
>
> If it's not readily available, I guess I could just use the size of a
> pointer on the target?
>
> Thanks again for your help here,
>   Steve
>
>
> On Sat, Feb 1, 2014 at 4:57 PM, Steve Pucci <spucci at google.com> wrote:
>
>> Great, thanks a lot, Richard.  I'll make the change you suggest to the
>> code I'm working on.
>>
>>  - Steve
>>
>>
>> On Sat, Feb 1, 2014 at 11:57 AM, Richard Mitton <richard at codersnotes.com>wrote:
>>
>>>  The definitive document is here: http://www.akkadia.org/drepper/tls.pdf
>>>
>>> I just had a look through and I guess it probably is a bug. Technically
>>> the code in DLYDRendezvous::GetThreadInfo() should query not only the
>>> location, but also the size of modid (using the same API), and then later
>>> issue the appropriately-sized read.
>>>
>>> It's not really "wrong" for little-endian systems right now, unless you
>>> have 4 billion modules loaded.
>>>
>>>
>>> Steve Pucci wrote:
>>>
>>> Hi all,
>>>
>>>  I'm trying to determine if some code in DynamicLoaderPOSIXDYLD is
>>> correct and I could use some confirmation:
>>>
>>>  The code in question reads the module id of a module as part of
>>> finding the TLS block associated with that module, by determining its
>>> location and then reading with a hardcoded 32-bit unsigned read.  (The code
>>> in question is
>>> source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp, in
>>> DynamicLoaderPOSIXDYLD::GetThreadLocalData).
>>>
>>>  I've read http://dev.gentoo.org/~dberkholz/articles/toolchain/tls.pdf, which describes a number of architectures and in all cases the value
>>> seems to be either size_t or "unsigned long int".  Thus the code appears to
>>> be wrong in at least some cases, in that it should be reading 64 bits when
>>> debugging 64-bit runtimes.  The code presumably works today for 64-bit LSB
>>> (little-endian) systems (which is most of the 64-bit Linuxes) because it's
>>> reading the right 32-bits out of the 64-bit location.
>>>
>>> But I'm not 100% sure, because
>>> * I'm not sure that the referenced pdf is definitive
>>> * I don't have an MSB 64-bit system to test on to verify that it's a bug.
>>>
>>>  Can anyone with any familiarity with this issue comment on this?
>>>
>>>  Thanks,
>>>    Steve
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> lldb-dev mailing listlldb-dev at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140203/247eff51/attachment.html>