| |
| |
| |
|
Page: 1 2
Comments:
<0> hi
<1> why do you figure the bound and into instruction are rarely used considering the obvious security implications they have?
<2> does anyone what's the purpose of an ***embler program (or many modules of an ***embler program ) having sections ( like .sect , or .bss .. and so on ) ?
<2> I know that in some sections you can put only data , in other sections you can put code , and in other sections like .sect you can put both ... but what's the purpose of this ?
<3> so you can put rights to the sections
<3> code has read and execute
<3> data has read write
<3> and you can`t have initialized and uninitialized data in one section
<2> ok, you said "code has read and execute " , so who can read and execute those ssections of code ?
<3> the system...
<3> and you
<3> if you try to write to that section a segfault occurs
<2> you mean write from within the program (the .asm file ) or from where ?
<3> ok, let me explain
<3> your program has these sections
<3> they are separated in the exe file
<3> and loaded separately
<3> text is copied i the memory
<3> uninitialized data is zeroed out
<3> and initialized data is also copied
<3> do you understand now?
<2> text is the .asm file , right ?
<3> NO
<3> text is compiled code
<3> the **** that actually runs
<3> the bytecode
<2> ok
<2> so uninitialise data and initialised data is not part of the text ?
<3> no
<2> ok, and when I say uninitialised data I should think of .. like a variable which is not initialised , ? and when say initialised data it's like a variable to which I gave a value in my .asm program ?
<3> yup
<2> my English is not that good so I have to ask : what's "zeroed out " ?
<3> what is your lang?
<2> romanian, :)
<3> eh, asa mai mere :)
<2> :)
<3> deci, umpluta cu zeroaie
<2> ya :) , da aici se poate vorbi altceva decat engleza ?
<3> cui ii pasa?
<2> :)
<3> deci, loaderu incarca programu, vede sectiune neinitializata, aloca memoria, o umple cu zero...
<3> vezi ca pe stiva nu ti`o goleste nimeni.. oricum daca scrii asm adevarat, fara magareli delea cu proc si altele, cum scrii in masm, atunci o vezi ca`i ebp-x
<2> da io nu-nteleg o chestie , de exemplu daca sistemu pe care o sa ruleze programul e de fapt un microcontroler, atunci loader-ul este pe microcontroler si nu pe pc (unde e asamblorul cu linkerul) nu ?
<3> mmm... daca e pe microcontroller atunci se schimba lucrurile...
<2> da ..? pai de ce ca si asta are sectiuni ..
<3> dah, dar astea `s mapate direct pe memoria chestiunii in cauza
<3> de ex .code o sa fie undeva in rom
<3> .data in ram
<3> astea trebuie specificate cu mana
<2> da am vazut si io asta cu Rom si Ram, da de fapt le specifici cu mana in .asm acolo unde zici ca incepi o sectiune , deci unde scrii de ex. " .sect sau .bss , nu ?
<3> cand declari sectiunea o sa`i scrii undeva pe langa si adresa, si accesu. oricum daca`i dai accesu gresit si incerci sa scrii in rom o sa`ti crape
<2> pai aia cu adresa am vazut ca se scrie , da' de acces n-am vazut nimic , aia cu accesul cum ar trebui sa arate in .asm ?
<3> depinde ce asamblor folosesti
<3> io nu prea ma pricep la astea, am scris programe de windows/linux pe calc si n`am programat microcontrolere pana acuma
<3> oricum, se gaseste in doxurile asamblorului
<2> oka, da de-asta zic ca in doxuri n-am vazut nimic legat de acces, numa despre adresele sectiunilor zice, si-atunci ma gandesc ca se poate sa nu fie partea cu accesu/drepturile , si-atunci tre sa revin la prima mea intrebare : ce rost are sa faci sectiuni , ca ziceai ca pt. a le da drepturi , da daca asamblorul asta al meu nu stie drepturi , atunci de ce naiba l-o facut sa stie sectiuni :) ?
<3> ca sa separi capra de varza
<2> :), da .pai io n-am prea separat pana acuma capra de varza ...
<3> deci mai, cand ii zici .code si adresa, atunci ii zici compilatorului: vezi ca codul e aici, ai grija cum asamblezi
<3> daca e vorba de un microcontroller atunci e obligatoriu sa separi datele de cod. pai daca asamblezi cu date in cod si sectiunea vine flash`uita in memorie si tu incerci sa scrii iti dai seama ca o sa crape
<2> pai la ucontrolerul meu , asamblorul lui stie o sectiune (.sect ) in care poti sa pui si cod si date si poti s-o denumesti cum vrei , si-atunci ma gandesc ca explicatia e ca sectiunea asta (.sect) nu e flash-uita , nu ?
<3> probabil .. weird
<3> cauta niste documentatie, asa pe neve nush peste ce o sa mai dai
<2> da ..ok .. oricum loader-ul ma gandesc ca poate sa fie numa pe ucontroller , nu ? ca doar n-are ce sa caute pe PC ..
<3> dah, io vorbeam de prog in windows/linux
<3> pe microcontrolere ai numa o adresa de unde se incepe executia, deci trb sa`ti pozitionezi codu` sa` pice unde trebuie
<2> aha
<2> da, pai atuncea asta o fi diferenta , ca daca asamblorul e pe PC si e pentru program ce-o sa ruleze pe PC atunci probabil ca aadresa de start a programului nu tre sa fie intotdeauna aceeasi , pentru ca este memorie mai multa decat pe ucontroler si se ocupa loader-ul sistemului de operare sa incarce la adresa la care ai zis tu in .asm ca incepe sectiunea
<3> nope
<2> la ucontroler ma gandesc ca tot loadeerul se ocupa sa incarce la adresa la care ai zis ca incepe sectiunea in asm, numai ca adresaa e intotdeauna aceeasi ca este memorie mai putina , nu ?
<2> nope ?
<2> da de ce ?
<3> de ex toate programele incep la 0x4000000
<3> cred ca am pus un 0 in plus
<3> pe windows
<3> :)
<3> dll`urile sunt incarcate care si pe unde
<2> pai is 6 de zero acolo, cati tebuiau sa fie ?
<2> aha
<3> oricum, os`ul isi permite sa faca rebase, si alte alea pe cand pe microcontroller aia e prima instructiune care se executa...
<2> rebase e totuna cu relocation ?
<3> aha
<4> i'm glad you found someone who speaks your language.
<2> da , tipul se bucura.. ... acuma ideea e ca n-am stiut de canalul asta ca intram mult mai devreme :) .. .. si acuma l-am gasit ca am zis : hai sa-ncerc sa-i dau join : #asm , poate exista canalu :) , asa l-am gasit :)
<5> o_O
<2> stie cineva care-i diferenta intre macro instructiuni si functii/proceduri intr-un limbaj de asamblare ?
<2> sorry
<2> does someone know what the difference is between macro instructoins and functions/procedures in an ***embller language ?
<5> those are 2 totally different terms
<5> so you want differences, where should i start ;)
<2> let's say the main difference !
<1> a macro doesn't imply a procedure/function?
<6> lol
<5> macro and functions are both set of instructions
<5> except if you call the macro 3 times it will take 3x(bytes of code) and for procedures 1x(bytes of code) (no matter the n times you call it)
<3> macrourile se execut INAINTE de compilare ... sunt bune ca sa iti tzii codul portabil si ca sa iti simplifici munca, sa nu mai scrii aceleasi bucati de j ori
<2> so when you say "bytes of code " I guess you mean machine code , right ?
<2> ca sa tii codul portabil , in ce sens ?
<2> se executa inainte de compilare chiar si in cazul limbajelor de asamblare ?
<3> macrourile nu sunt cod
<5> either talk English or whatever, i will now stop answering your questions
<3> let`s talk in english
<2> ok , sorry , my question was : so when you say "bytes of code " I guess you mean machine code , right ?
<2> BoR0 ?
<5> if your macro takes 3 bytes of code, and you call it 3 times, it will take 9 bytes
<5> if your function takes 3 bytes of code, and you call it n times, it will take 3 bytes (+ the CALL instruction)
<6> corex: i already explained you what you had asked, why bother with the same question ?
<5> macros are invented for readability of code
<5> say you have
<5> m2m macro reg1
<5> push reg1
<5> pop reg1
<5> m2m endm
<5> and in code you have "m2m eax" the ***embler will just replace every m2m found with the code in the macro
<5> you can download ollydbg (www.ollydbg.com) which will show you what its translated to so you can see it far better than explained here :)
<1> are you familar with C or C++ ?
<6> =))
<2> ok, and that eplacement is done before ***embling ?
<3> let me give you an example: i have a function a that differs in implementation from os to os. i can write a macro that detects on what os i am compiling and enable only the implementation for the machine i am compiling on, thus keeping the code portable
<5> yes, preprocessor
<2> ike' , is that possible on ***embly language ?
<3> ofcourse
<5> ike: portability with ***embler? thats a very bad idea
<1> presuming each os runs on the same type of processor
<3> well, you can use it to tune your app for a specific processor
<5> ike: what ***embler are you referring to?
<3> and that`s a verry GOOD idea
<5> is there an ***embler that runs on every processor?
<2> I'm confused here, I've only seen that in c, o c++, and I thought that were called directives ...
<1> he's talking about different version's of the same processor
<3> yup
<1> i.e. 80486 and Pentium
<3> yup
<1> not intel and sparc
<5> ah, that is different
<1> corex
<1> think of macro's as #define's
<1> because thats exactly what they are
<3> they are called macros even in c..
<1> #define foo(msg, fmt) do { printf(fmt, msg); } while (0)
<1> eh that was a bad example as i dont want to type that all out in asm ;]
<2> so #define is called a macro and not a directive in c ?
<1> no, its a macro
<1> it may be called a directive somewhere as well
<1> but ive never heard it called that
<5> corex: its the preprocessor thing
<1> when you compile a c program
<5> as ike's macro, compare it with #IF and #ELSEIF
<1> the preprocessor is first run over it
Return to
#asm
or
Go to some related
logs:
gnuworld cvs no route to host
cum sa dai flood
midnightlvr1
#MissKitten
fwNES cannot execute
assemble example int 13h
#MissKitten
#london
#AllNiteCafe
supress dsget succeeded
|
|