gdb not working

[Ken Brown]

On 1/18/2021 8:54 AM, Lemke, Michael SF/HZA-ZIC2 wrote:
> On Monday, January 18, 2021 2:23 PM Marco Atzeri wrote:
>> On 18.01.2021 14:08, Lemke, Michael SF/HZA-ZIC2 wrote:
>>> On Friday, January 15, 2021 9:02 PM Ken Brown wrote:
>>>> On 1/15/2021 1:47 PM, Lemke, Michael SF/HZA-ZIC2 wrote:
>>>>> On Friday, January 15, 2021 4:45 PM Jon Turney wrote:
>>>>>> On 15/01/2021 12:28, Lemke, Michael wrote:
>>>>>>> I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe.
>>>>>>> However, gdb does not produce any output.
>>>>>>>
>>>
>>>>
>>>>> Also ldd `which gdb` is
>>>>> fine.
>>>>
>>>> Please show the output.
>>>
>>> pc> ldd `which gdb`
>>
>>>           cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf60000)
>>>           cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3f8840000)
>>
>>>           cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x170000)
>>                                                 this is very low ^^^^
>>>           cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3600000)
>>
>>>           cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x3fc240000)
>>>           cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x3600000)
>>
>>
>> I do not see duplicate entries on my system. it seems a BLODA
>> is interfering with dll's loading
>>
> 
> It might very well be. I also noticed the output of ldd is not reproducible.
> It shows different duplicate entries when run repeatedly and the load
> address you marked is also a duplicate:
> 
>   pc> ldd `which gdb`|grep --color gcc
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf60000)
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x170000)
>   pc> ldd `which gdb` | grep --color gcc
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf60000)
>   pc> ldd `which gdb` | grep --color gcc
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf60000)
>   pc> ldd `which gdb` | grep --color gcc
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf60000)
>   pc> ldd `which gdb` | grep --color gcc
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf60000)
>   pc> ldd `which gdb` | grep --color gcc
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf60000)
>   pc> ldd `which gdb` | grep --color gcc
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf60000)
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x170000)
>   pc> ldd `which gdb` | grep --color gcc
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf60000)
>   pc> ldd `which gdb` | grep --color gcc
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf60000)
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0xa0000)
> 
> Hm, is gdb dependent on gcc? I just noticed my gcc is apparently broken:
>   pc> cygcheck -c gcc
> Cygwin Package Information
> Package              Version        Status

The package containing gcc is called "gcc-core", not "gcc":

$ cygcheck -f /usr/bin/gcc.exe
gcc-core-10.2.0-1

$ cygcheck -c gcc-core
Cygwin Package Information
Package              Version        Status
gcc-core             10.2.0-1       OK

> Other than going through the published BLODA list is there a way I could
> test and find out what is interfering? I ask because we have a lot of
> stuff installed for teleworking, especially on the network side.

You can sometimes catch BLODA by running strace.  It may show some DLL being 
loaded that shouldn't be, typically from security software.

Ken