@tboeckel
Thanks, I noted that too and I did consult Wipeout doc before posting the question. It still does not explain much of the output you get (even when i run sashimi too) I was hoping more guidance would exist somewhere. Did not find it with extensive internet searching though.
Do i have to learn asm to understand the output? What are the different output sections corresponding to one hit? If an illegal memory alloc is mentioned, can the given info help me to find the source line?
Just post the output lines which you didn't understand and some of us can explain them.
As for the source lines, its usually can be find by the addr2line (if the binary was compiled with -gstabs). Check that topic, maybe it will give you some more info about.
@kas1e
Here is an output in which i even did not had my program under test (Gui4Cli or gui4 its launcher)running
I could relate the recurrent "Date" hit to TitleClock which was in my WBStartup , although not really used in the WBTitle and unchecked in the WBStartUp list.
It may be that the "Wait" hit comes from there too.
I have been plagued at startup with console oputput telling me that Date was made resident, and i also observed that for wait (although really just recently once) I expect both to be gone now, since i deleted TitkleClock entirely from WBSatrtUp. OK that's the context
I did visit the thread, which was usefull indeed.
Now following a 'Date' hit in the output beneath:
- i understand first 2 lines,
- then comes a list 8: 16: 24: 32 memory addresses of which 13 seem to be explained in the 13 lines below (how were they generated, how was the selection done producing the 13 adresses retained?)
- these 13 lines ----> point to 'segments' & offsets . my understanding is that segments refer to how the executable is stored on disk 'segments' that ar loaded as a list probably too at thememory adresses given just after the arrow
From Wipeout doc i guess 'Segtracker' can transform that in usable info??? but i also think segtracker only works under OS3.x
LR 01641020:"Kickstart/newlib.library.kmod" segment 0000 offset 2ddc
CTR 6f9759c8 :"memguard" segment 0005 offset 89c0
Contrary to the example in other thread we have an additional LRa & CTRa ???
Here too LR(a) does not point to some 'Date' address (not to DOS either). Does it mean Date is OK?
Then why rhe hit ??
The Stack backtrace ressembles grimreaper crashlog output except how addresses are given (Segtracker needed to deconde them?)
Then a disassembly for which you obviously need to understand assembler code. (Or you could write a simple translation table to a more verbose pseudo command, starting with most common commands, maybe such a list exists?)
And finally stuff i don't understand and how it could help me.
Anyway, clarifying these, as well as relations betweeen sections that i missed, would be interesting, not only to me. Simplifying the output automatically to just what can be used directly with other tools say addr2line (eg with a Gui4Cli script) would then be possible.
Thanks for any additional clarification?
If this is possible, i wouldn't mind this text being corrected and expanded.
Segments there mean sections of the binary constructed in the memory and offsets in them. Some time someone call section like segments, or segments like sections, but that is some terminology crap, and sometime its all messing around, so you just can think that its kind of the same. But if you worry about exact terminolyg, then there is relevant part from again, that "hacking way" article:
-----
Although it may seem that sections and segments are the same thing, this is not the case. Sections are elements of the ELF file. When you load the file into memory, sections are joined to form segments. Segments are file elements too but they are loaded to memory and can be directly handled by the loader. So you can think of sections as segments, just you should know that segments are something that executes in memory, while sections is the material from which segments are built in memory.
------
Whole ELF binary contain bunch of sections/segments (depends if we refers to memory or to file, but let's it be the same for now), like .data (for data), .text (for code) and all bunch of other ones (but those 2 are important ones). The whole list of sections/segments you can find in the ELF specitication, or , again you can check my "hacking way" article where i explain how to hack ELF files, to get some begining stuff (+ links on necessary pdfs).
With your example we have a references to segments 0000, 0001, 0004 and 0005 and offtets in them. Now you need to know what they mean: so you just again refer to books/specifications, or just use "readelf" from os4 sdk (which is better, because there can be os4 specific differences). For example, just "readelf -a c:date", and you will see what number of sections have. Segment 0001 mean .text (code), segment 0004 and 00005 mean different kind of data (.sdata and .sbss), and so on. Then, if you still feel you brave, you then can disassemble only necessary parts to which segments / offsets debug tools point out (by objdump or IDA as i say before).
Through ts all will be pain because you have no debug info in those binaries, nor sources of them. But when its all about your own code, then all that info can be pretty helpfull (it can be helpfull of course and in case with debugging crashes in not your programs, just all will be harder)
Thanks a lot also for your "hacking way " article and your proposal to help with more questions.
I get some idea now of what i have to learn first in the debugging field (for difficult bugs freezes etc) I'll have more questions later.
And no, i had no intention to look for bugs in Date or Wait: just a memguard output i had at hand.
This is the very first paragraph of MemGuard's "documentation":
Shouldn't this ring a bell to take a look in the docs of the mentioned programs?
Wipeout's docs contain all the necessary information.
@tboeckel
Thanks, I noted that too and I did consult Wipeout doc before posting the question. It still does not explain much of the output you get (even when i run sashimi too) I was hoping more guidance would exist somewhere. Did not find it with extensive internet searching though.
Do i have to learn asm to understand the output? What are the different output sections corresponding to one hit? If an illegal memory alloc is mentioned, can the given info help me to find the source line?
@JosDuchIt
Just post the output lines which you didn't understand and some of us can explain them.
As for the source lines, its usually can be find by the addr2line (if the binary was compiled with -gstabs). Check that topic, maybe it will give you some more info about.
@kas1e
Here is an output in which i even did not had my program under test (Gui4Cli or gui4 its launcher)running
I could relate the recurrent "Date" hit to TitleClock which was in my WBStartup , although not really used in the WBTitle and unchecked in the WBStartUp list.
It may be that the "Wait" hit comes from there too.
I have been plagued at startup with console oputput telling me that Date was made resident, and i also observed that for wait (although really just recently once) I expect both to be gone now, since i deleted TitkleClock entirely from WBSatrtUp. OK that's the context
I did visit the thread, which was usefull indeed.
Now following a 'Date' hit in the output beneath:
- i understand first 2 lines,
- then comes a list 8: 16: 24: 32 memory addresses of which 13 seem to be explained in the 13 lines below (how were they generated, how was the selection done producing the 13 adresses retained?)
- these 13 lines ----> point to 'segments' & offsets . my understanding is that segments refer to how the executable is stored on disk 'segments' that ar loaded as a list probably too at thememory adresses given just after the arrow
From Wipeout doc i guess 'Segtracker' can transform that in usable info??? but i also think segtracker only works under OS3.x
- then 4 lines
Contrary to the example in other thread we have an additional LRa & CTRa ???
Here too LR(a) does not point to some 'Date' address (not to DOS either). Does it mean Date is OK?
Then why rhe hit ??
The Stack backtrace ressembles grimreaper crashlog output except how addresses are given (Segtracker needed to deconde them?)
Then a disassembly for which you obviously need to understand assembler code. (Or you could write a simple translation table to a more verbose pseudo command, starting with most common commands, maybe such a list exists?)
And finally stuff i don't understand and how it could help me.
Anyway, clarifying these, as well as relations betweeen sections that i missed, would be interesting, not only to me. Simplifying the output automatically to just what can be used directly with other tools say addr2line (eg with a Gui4Cli script) would then be possible.
Thanks for any additional clarification?
If this is possible, i wouldn't mind this text being corrected and expanded.
Segments there mean sections of the binary constructed in the memory and offsets in them. Some time someone call section like segments, or segments like sections, but that is some terminology crap, and sometime its all messing around, so you just can think that its kind of the same. But if you worry about exact terminolyg, then there is relevant part from again, that "hacking way" article:
-----
Although it may seem that sections and segments are the same thing, this is not the case. Sections are elements of the ELF file. When you load the file into memory, sections are joined to form segments. Segments are file elements too but they are loaded to memory and can be directly handled by the loader. So you can think of sections as segments, just you should know that segments are something that executes in memory, while sections is the material from which segments are built in memory.
------
Whole ELF binary contain bunch of sections/segments (depends if we refers to memory or to file, but let's it be the same for now), like .data (for data), .text (for code) and all bunch of other ones (but those 2 are important ones). The whole list of sections/segments you can find in the ELF specitication, or , again you can check my "hacking way" article where i explain how to hack ELF files, to get some begining stuff (+ links on necessary pdfs).
With your example we have a references to segments 0000, 0001, 0004 and 0005 and offtets in them. Now you need to know what they mean: so you just again refer to books/specifications, or just use "readelf" from os4 sdk (which is better, because there can be os4 specific differences). For example, just "readelf -a c:date", and you will see what number of sections have. Segment 0001 mean .text (code), segment 0004 and 00005 mean different kind of data (.sdata and .sbss), and so on. Then, if you still feel you brave, you then can disassemble only necessary parts to which segments / offsets debug tools point out (by objdump or IDA as i say before).
Through ts all will be pain because you have no debug info in those binaries, nor sources of them. But when its all about your own code, then all that info can be pretty helpfull (it can be helpfull of course and in case with debugging crashes in not your programs, just all will be harder)
If you have any other questions about just ask.
@kas1e
Thanks a lot also for your "hacking way " article and your proposal to help with more questions.
I get some idea now of what i have to learn first in the debugging field (for difficult bugs freezes etc) I'll have more questions later.
And no, i had no intention to look for bugs in Date or Wait: just a memguard output i had at hand.
@JosDuchIT
Just to add about memguard's LRa and CTRa. From memguard docs:
So it's the value at the point of memory-allocation. And without 'a' it's seems at release- or accesss-time.