On Friday 01 October 2010 18:10:57 Jan Palus wrote:
On 28.09.2010 20:11, Jan Palus wrote:
Od jakiegos czasu staram sie zdiagnozowac dlaczego valgrind nie uzywa
plikow debuginfo. Przez przypadek natknalem sie na biblioteke z ktora
sobie radzi, mianowicie expat zbudowany rok temu. Roznica
On 01.10.2010 19:36, Paweł Sikora wrote:
nigdzie nie przepada, bo *aktualnie* nie jest tworzona.
aktualnie w th nie tworzy sie ta sekcja poniewaz uzywamy build-id
z ktorym gdb radzi sobie doskonale. pakiet expat, to tylko wyjatek
ktory jeszcze nie zostal zrekompilowany w th.
Chodzilo mi o to
On 01.10.2010 20:09, Patryk Zawadzki wrote:
2010/10/1 Jan Palus jan.pa...@gmail.com:
On 01.10.2010 19:36, Paweł Sikora wrote:
usuniety plik $t to jest wystripowana do cna binarka i w pld-th
zadnego debuginfo tam nie ma. zmiana jak najbardziej prawidlowa.
debuginfo nie ma, ale ma
2010/10/1 Jan Palus jan.pa...@gmail.com:
On 01.10.2010 20:09, Patryk Zawadzki wrote:
Znaczy się wynikowa, obrana binarka ma więcej pól nagłówka, niż
nienaruszona źródłowa? Bo -o było dodane właśnie po to, żeby eu-strip
nie ruszał oryginalnego pliku.
Odnosilem sie do usuwanego pliku $t.
On 01.10.2010 20:23, Patryk Zawadzki wrote:
Plik $t jest tworzony linijkę przed jego usunięciem. Może się mylę,
ale zwykle pliki elf w wyniku stripowania zawierają mniej informacji,
niż oryginalna binarka. W każdym razie tradycją jest, że ich nie
przybywa.
Jeśli nie potrafisz udowodnić, że
2010/10/1 Jan Palus jan.pa...@gmail.com:
% readelf -S lib.so|grep debuglink
% eu-strip -f lib.so.debug lib.so -o lib-stripped.so
% readelf -S lib-stripped.so|grep debuglink
[25] .gnu_debuglink PROGBITS 00b238 14 00 0 0
4
Myslalem ze to oczywiste. Rozumiem
On Wed, Sep 22, 2010 at 04:48:15PM +0200, Patryk Zawadzki wrote:
Jest jeszcze brzydziej, niż było. Tam nie powinno być ani deepcopy,
ani tym bardziej piklowania. Powinno być normalne utworzenie obiektu i
przepisanie istotnych atrybutów.
Napewno masz rację... ALE DZIAŁA!!! DZIĘKI PEPE! :)
