* teaching gdb about new types?
@ 2011-04-29 18:36 Richard Silverman
2011-04-29 18:57 ` Paul Koning
0 siblings, 1 reply; 6+ messages in thread
From: Richard Silverman @ 2011-04-29 18:36 UTC (permalink / raw)
To: GDB Mailing List
Hello,
This seems as if it should be simple, but I can't find an answer. I would like to teach gdb about new types relevant to the program being debugged, which are not among the debugging info in the program. A concrete example: I have a program which uses pthreads from libc. It calls:
int pthread_cond_wait(pthread_cond_t *restrict cond,
pthread_mutex_t *restrict mutex);
... and the argument types are defined in system header files. But libc.so has no debugging info, so gdb doesn't know about these types, and can't interpret the arguments for me. How can I teach gdb about these types?
Thanks,
- Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: teaching gdb about new types?
2011-04-29 18:36 teaching gdb about new types? Richard Silverman
@ 2011-04-29 18:57 ` Paul Koning
2011-04-29 20:43 ` Richard Silverman
0 siblings, 1 reply; 6+ messages in thread
From: Paul Koning @ 2011-04-29 18:57 UTC (permalink / raw)
To: Richard Silverman; +Cc: GDB Mailing List
The simple answer is to get a copy of libc.so with debug symbols, and load that symbol table. You don't have to replace the library itself to do that.
paul
On Apr 29, 2011, at 2:36 PM, Richard Silverman wrote:
> Hello,
>
> This seems as if it should be simple, but I can't find an answer. I would like to teach gdb about new types relevant to the program being debugged, which are not among the debugging info in the program. A concrete example: I have a program which uses pthreads from libc. It calls:
>
> int pthread_cond_wait(pthread_cond_t *restrict cond,
> pthread_mutex_t *restrict mutex);
>
> ... and the argument types are defined in system header files. But libc.so has no debugging info, so gdb doesn't know about these types, and can't interpret the arguments for me. How can I teach gdb about these types?
>
> Thanks,
>
> - Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: teaching gdb about new types?
2011-04-29 18:57 ` Paul Koning
@ 2011-04-29 20:43 ` Richard Silverman
2011-04-29 20:53 ` Paul Koning
0 siblings, 1 reply; 6+ messages in thread
From: Richard Silverman @ 2011-04-29 20:43 UTC (permalink / raw)
To: Paul Koning; +Cc: GDB Mailing List
On Fri, 29 Apr 2011, Paul Koning wrote:
> The simple answer is to get a copy of libc.so with debug symbols, and load that symbol table. You don't have to replace the library itself to do that.
>
> paul
I know, thanks; but the host is Solaris, and Oracle doesn't appear to provide this (although I'm pursuing it with them.). I could also build the OpenSolaris libc and hope they're close enough. However, it really seems as if one ought to be able to do what I described.
- Richard
> On Apr 29, 2011, at 2:36 PM, Richard Silverman wrote:
>
>> Hello,
>>
>> This seems as if it should be simple, but I can't find an answer. I would like to teach gdb about new types relevant to the program being debugged, which are not among the debugging info in the program. A concrete example: I have a program which uses pthreads from libc. It calls:
>>
>> int pthread_cond_wait(pthread_cond_t *restrict cond,
>> pthread_mutex_t *restrict mutex);
>>
>> ... and the argument types are defined in system header files. But libc.so has no debugging info, so gdb doesn't know about these types, and can't interpret the arguments for me. How can I teach gdb about these types?
>>
>> Thanks,
>>
>> - Richard
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: teaching gdb about new types?
2011-04-29 20:43 ` Richard Silverman
@ 2011-04-29 20:53 ` Paul Koning
2011-04-30 3:02 ` Richard Silverman
0 siblings, 1 reply; 6+ messages in thread
From: Paul Koning @ 2011-04-29 20:53 UTC (permalink / raw)
To: Richard Silverman; +Cc: GDB Mailing List
If you're worried about types rather than line numbers, I would think that all you'd need is a symbol table that has the right type definitions in it. If you know what they are supposed to be, you can supply such a symbol table easily enough.
paul
On Apr 29, 2011, at 4:42 PM, Richard Silverman wrote:
> On Fri, 29 Apr 2011, Paul Koning wrote:
>
>> The simple answer is to get a copy of libc.so with debug symbols, and load that symbol table. You don't have to replace the library itself to do that.
>>
>> paul
>
> I know, thanks; but the host is Solaris, and Oracle doesn't appear to provide this (although I'm pursuing it with them.). I could also build the OpenSolaris libc and hope they're close enough. However, it really seems as if one ought to be able to do what I described.
>
> - Richard
>
>> On Apr 29, 2011, at 2:36 PM, Richard Silverman wrote:
>>
>>> Hello,
>>>
>>> This seems as if it should be simple, but I can't find an answer. I would like to teach gdb about new types relevant to the program being debugged, which are not among the debugging info in the program. A concrete example: I have a program which uses pthreads from libc. It calls:
>>>
>>> int pthread_cond_wait(pthread_cond_t *restrict cond,
>>> pthread_mutex_t *restrict mutex);
>>>
>>> ... and the argument types are defined in system header files. But libc.so has no debugging info, so gdb doesn't know about these types, and can't interpret the arguments for me. How can I teach gdb about these types?
>>>
>>> Thanks,
>>>
>>> - Richard
>>
>>
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: teaching gdb about new types?
2011-04-29 20:53 ` Paul Koning
@ 2011-04-30 3:02 ` Richard Silverman
2011-05-10 23:42 ` Doug Evans
0 siblings, 1 reply; 6+ messages in thread
From: Richard Silverman @ 2011-04-30 3:02 UTC (permalink / raw)
To: Paul Koning; +Cc: GDB Mailing List
On Fri, 29 Apr 2011, Paul Koning wrote:
> If you're worried about types rather than line numbers, I would think that all you'd need is a symbol table that has the right type definitions in it. If you know what they are supposed to be, you can supply such a symbol table easily enough.
>
> paul
I tried that -- I created a little file:
----------------------------------------
#include <pthreads.h>
pthread_cond_t p;
pthread_mutex_t m;
----------------------------------------
... and built an object from it. However, I can't find a way to get gdb to use it while debugging an existing program, that is, to add the type definitions in that object to its existing set. The commands "symbol-file" and "add-symbol-file" seem likely candidates, but they don't appear to do it.
- Richard
> On Apr 29, 2011, at 4:42 PM, Richard Silverman wrote:
>
>> On Fri, 29 Apr 2011, Paul Koning wrote:
>>
>>> The simple answer is to get a copy of libc.so with debug symbols, and load that symbol table. You don't have to replace the library itself to do that.
>>>
>>> paul
>>
>> I know, thanks; but the host is Solaris, and Oracle doesn't appear to provide this (although I'm pursuing it with them.). I could also build the OpenSolaris libc and hope they're close enough. However, it really seems as if one ought to be able to do what I described.
>>
>> - Richard
>>
>>> On Apr 29, 2011, at 2:36 PM, Richard Silverman wrote:
>>>
>>>> Hello,
>>>>
>>>> This seems as if it should be simple, but I can't find an answer. I would like to teach gdb about new types relevant to the program being debugged, which are not among the debugging info in the program. A concrete example: I have a program which uses pthreads from libc. It calls:
>>>>
>>>> int pthread_cond_wait(pthread_cond_t *restrict cond,
>>>> pthread_mutex_t *restrict mutex);
>>>>
>>>> ... and the argument types are defined in system header files. But libc.so has no debugging info, so gdb doesn't know about these types, and can't interpret the arguments for me. How can I teach gdb about these types?
>>>>
>>>> Thanks,
>>>>
>>>> - Richard
>>>
>>>
>>>
>
>
>
--
Richard Silverman
res@qoxp.net
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: teaching gdb about new types?
2011-04-30 3:02 ` Richard Silverman
@ 2011-05-10 23:42 ` Doug Evans
0 siblings, 0 replies; 6+ messages in thread
From: Doug Evans @ 2011-05-10 23:42 UTC (permalink / raw)
To: Richard Silverman; +Cc: Paul Koning, GDB Mailing List
On Fri, Apr 29, 2011 at 8:02 PM, Richard Silverman <res@qoxp.net> wrote:
> On Fri, 29 Apr 2011, Paul Koning wrote:
>
>> If you're worried about types rather than line numbers, I would think that
>> all you'd need is a symbol table that has the right type definitions in it.
>> If you know what they are supposed to be, you can supply such a symbol
>> table easily enough.
>>
>> paul
>
> I tried that -- I created a little file:
>
> ----------------------------------------
> #include <pthreads.h>
>
> pthread_cond_t p;
> pthread_mutex_t m;
> ----------------------------------------
>
> ... and built an object from it. However, I can't find a way to get gdb to
> use it while debugging an existing program, that is, to add the type
> definitions in that object to its existing set. The commands "symbol-file"
> and "add-symbol-file" seem likely candidates, but they don't appear to do
> it.
I've used add-symbol-file to accomplish exactly this kind of thing.
Can you elaborate on what didn't work?
Here's a quick example to illustrate.
bash$ cat foo.c
#include <pthread.h>
pthread_cond_t p;
pthread_mutex_t m;
bash$ gcc -g -c foo.c
bash$ gdb hello.x
[...]
(gdb) pty pthread_cond_t
No symbol "pthread_cond_t" in current context.
(gdb) add-symbol-file foo.o 0
add symbol table from file "foo.o" at
.text_addr = 0x0
(y or n) y
(gdb) pty pthread_cond_t
type = union {
struct {
int __lock;
unsigned int __futex;
long long unsigned int __total_seq;
long long unsigned int __wakeup_seq;
long long unsigned int __woken_seq;
void *__mutex;
unsigned int __nwaiters;
unsigned int __broadcast_seq;
} __data;
char __size[48];
long long int __align;
}
(gdb)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-05-10 23:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-29 18:36 teaching gdb about new types? Richard Silverman
2011-04-29 18:57 ` Paul Koning
2011-04-29 20:43 ` Richard Silverman
2011-04-29 20:53 ` Paul Koning
2011-04-30 3:02 ` Richard Silverman
2011-05-10 23:42 ` Doug Evans
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox