wrong assumptions about pthread_t being numeric

[John Spencer]

On 09/17/2011 01:00 AM, Pedro Alves wrote:
>
> These are only built natively on solaris and aix respectively, so
> let's just leave them alone.
>

I expected it to be desirable for a product in industrial use to be 
standard-compliant and not invoking undefined behavior.

>> thread-db.c: In function 'find_one_thread':
>> thread-db.c:295:7: error: format '%ld' expects type 'long int', but
>> argument 3 has type 'thread_t'
>> thread-db.c: In function 'attach_thread':
>> thread-db.c:335:7: error: format '%ld' expects type 'long int', but
>> argument 3 has type 'thread_t'
>> thread-db.c:341:9: error: format '%ld' expects type 'long int', but
>> argument 2 has type 'thread_t'
> So just cast it to long, and you're done.
>

pthread_t could legally be a struct, which you can't just cast to a long.


>> gdb-7.3.1/gdb/linux-thread-db.c:  gdb_assert (ti_p->ti_tid != 0);
>> gdb-7.3.1/gdb/linux-thread-db.c:  private->tid = ti_p->ti_tid;
>> gdb-7.3.1/gdb/linux-thread-db.c:  if (ti.ti_tid == 0&&
>> target_has_execution)
>> gdb-7.3.1/gdb/gdbserver/thread-db.c:         ti.ti_tid, ti.ti_lid);
>> gdb-7.3.1/gdb/gdbserver/thread-db.c:  if (ti.ti_tid == 0)
>> gdb-7.3.1/gdb/gdbserver/thread-db.c:         ti_p->ti_tid, ti_p->ti_lid);
>> gdb-7.3.1/gdb/gdbserver/thread-db.c:           ti_p->ti_tid, ti_p->ti_lid);
> Does your libc actually have a libthread_db.so?
>
no, that's another problem. the code just assumes it is there.

i had to use a couple of patches to make gdb compile.
if you are interested, the cumulative patch is available here 
http://pastie.org/private/rx05yywro1utmvvniw6gjw

-- JS