RE: pc 0x25c9b0 in read in psymtab, but not in symtab

["Elmenthaler, Jens" <jens dot elmenthaler at verigy dot com>]

> Sadly, without reproducer I won't get far.

In my case, the addresses complained about resolves to the following locations (RedHat Enterprise Linux 5.3):

maint translate-address 0x25c9b0
-> _dl_debug_state + 0 in section .text of /lib/ld-linux.so.2
maint translate-address 0x25c9b1
-> _dl_debug_state + 1 in section .text of /lib/ld-linux.so.2

This makes perfectly sense, as I see the messages while (or shortly after) the gdb is stopped because of shared library event.

I'm running out of time, right now. But a guess a program that dlopen's a shared library could be good candidate. I will give it a try as soon as possible.

Jens.

-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Tristan Gingold
Sent: Freitag, 8. Januar 2010 16:56
To: Chris Sutcliffe
Cc: gdb@sourceware.org
Subject: Re: pc 0x25c9b0 in read in psymtab, but not in symtab


On Jan 8, 2010, at 4:42 PM, Chris Sutcliffe wrote:

>> yes this bug I encounter some time ago, too. It is related to DLL files
>> not having any debugging information but are shown in backtrace. Here it
>> warns once about psymtab != symtab and code in gdb fix it afterwards. IMHO
>> this warning is simply pretty bogus here, or the DLL loader should
>> generate for pe-coff the symtab, too.
> 
> Hopefully this is helpful.

Not that much.  This doesn't sound coherent to me because if there is no debugging information both the
psymtab and the symtab should be empty.

> If there is anything else I can do to help track down the bug, please
> let me know.

It would be nice to have a reproducer.  It doesn't need to be small and I think sources are not needed
to investigate this issue.

Sadly, without reproducer I won't get far.

Tristan.