No debugging symbols found?

[Verwijderd]

Weet iemand misschien waarom je geen debugging symbols krijgt als je /bin/ping onder gdb uitvoerd. En of er misschien er andere manier is om de source code van /bin/ping te kunnen
in zien? Dit geeft die namelijk nu weer :

Starting program : /bin/ping
(no debugging symbols found) ... ( no debugging systembols found)
Usage: ping [-LRUbdfnrqvVaA] [-c count ] [-i interval] [-w deadline]
[-p pattern] [-s packetsize] [ -t ttl] [-i inferface or address]
[-M mtu discovery hint ] [-S sndbuf]
[ -T timestamp option ] [ -Q tos ] [hop1 ...] destination
no debugging symbols found)...
Program exited with code 02.
(gdb) break main
Function "main"not defined.
(gdb) break _start
Cannot access memory at adress 0x400000a80
(gdb)

[blaataaps]

Je vermeldt niet welk besturingssysteem je draait, maar zo'n beetje elk zinnig OS verscheept de binary's "stripped", ontdaan van debugging symbols dus, zo ook ping, zie bijvoorbeeld de output van "file":

code:

/usr/sbin/ping: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped

Ik snap ook niet helemaal hoe je via gdb de source wil opduikelen; ook met debugging symbols zit die source er niet ingebakken ofzo, de source kun je (afhankelijk van het OS, maar dat vermeld je niet) los downloaden misschien. Ook zal er als user weinig te gdb'en zijn aan ping normaliter, want die binary is meestal suid.

[Verwijderd]

Je vermeldt niet welk besturingssysteem je draait, maar zo'n beetje elk zinnig OS verscheept de binary's "stripped", ontdaan van debugging symbols dus, zo ook ping, zie bijvoorbeeld de output
van "file":

Draai suse linux 7.0 met intel x86 processor. Dacht via gdb kon debuggen net als je bv een execubtable c file met gcc dat kan en zo de assembly code con bekijken. Maar alleen met /bin/ping geeft die no debugging symbols weer.

[Creepy]

Dat is ook niet zo vreemd aangezien je geen debugging informatie in normale executables wilt hebben aangezien dat overbodig is bij normaal gebruik.
Daarnaast kan je van ping e.d. prima de volledige sourcecode verkrijgen aangezien het o.a. bij SuSe onder de GPL gedistribueerd wordt.

[Verwijderd]

Daarnaast kan je van ping e.d. prima de volledige sourcecode verkrijgen aangezien het o.a. bij SuSe onder de GPL gedistribueerd wordt.

Dus als ik het goed begrijp kan je via GPL de source van /bin/ping terug halen?

[blaataaps]

Natuurlijk niet, je haalt van alles doorelkaar, de GPL (zie bijvoorbeeld [google=GPL], zoals je zelf ook had kunnen zien) is een licensietype, die in dit geval waarborgt dat suse de source van /bin/ping (aannemende dat hun ping GPL is) ergens moet aanbieden, hoe en waar is vast wel ergens te vinden op de site van suse, of in de documentatie.

Dacht via gdb kon debuggen net als je bv een execubtable c file met gcc dat kan en zo de assembly code con bekijken.

Ik heb werkelijk geen idee wat je hier probeert te zeggen en wat je nou wil bereiken.

[ Voor 6% gewijzigd door blaataaps op 19-08-2007 21:25 ]

[Verwijderd]

Ik heb werkelijk geen idee wat je hier probeert te zeggen en wat je nou wil bereiken.

Ik probeer de c/c++ code te achter halen van het programma /bin/ping.

[blaataaps]

Waarom stel je dan allemaal andere vragen?
Zie bijvoorbeeld [google=ping.c].

[ Voor 13% gewijzigd door blaataaps op 19-08-2007 21:39 ]

[Verwijderd]

Verbaasde me gewoon waarom die niet dat hele proces onder gdb kon debuggen. Nou leuker was met gdb als dat kon om zo ook assembly erbij te leren. Maar via ping.c krijg je allemaal die lame tutorials enzo. Want als je bv strace ping (router) doet geeft die hele andere functies als bv een ping.c

[whoami]

Ehm, dit is geen SEA hoor.
Programming of DTE, ok, maar SEA is het niet.

Verder is het idd zinloos om een executable die gereleased is te debuggen, aangezien de debug symbols idd (als het goed is) niet meegereleased worden. (release build vs debug build).

En gewoon zoeken naar ping.c is idd veel efficienter. Vandaar: topic dicht

[ Voor 3% gewijzigd door whoami op 19-08-2007 22:02 ]