Re: [so] [Tema3][Windows] - Permisiuni VirtualAlloc, VirtualProtect
Pentru handlerul default pe Windows trebuie să returnezi ceva cu CONTINUE_SEARCHING din handlerul apelat de sistem. Honestly chestia asta e mai ușoară pe Windows decât pe Linux. Sent from Mail for Windows 10 From: Ionuț Mihalache via so Sent: Tuesday, April 16, 2019 12:01 AM To: Sisteme de Operare Subject: [so] [Tema3][Windows] - Permisiuni VirtualAlloc, VirtualProtect Salut, Se poate uita cineva din echipa va rog daca permisiunile din parametri pentru VirtualAlloc si VirtualProtect sunt in regula? Si nu stiu exact cum sa fac cu handler-ul default insa nu asta este problema acum ci faptul ca primesc segmentation fault in loader si cred ca este de la mapare. Multumesc. https://gitlab.cs.pub.ro/ionut.mihalache1506/l3-so-assignments/blob/master/3-loader/skel-win/loader.c ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
[so] [Tema3][Windows] - Permisiuni VirtualAlloc, VirtualProtect
Salut, Se poate uita cineva din echipa va rog daca permisiunile din parametri pentru VirtualAlloc si VirtualProtect sunt in regula? Si nu stiu exact cum sa fac cu handler-ul default insa nu asta este problema acum ci faptul ca primesc segmentation fault in loader si cred ca este de la mapare. Multumesc. https://gitlab.cs.pub.ro/ionut.mihalache1506/l3-so-assignments/blob/master/3-loader/skel-win/loader.c ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [SO] A doua lucrare de curs
Salut, Lucrările au fost recorectate, iar notele au fost actualizate în Catalog. Numai bine, Costin În mar., 9 apr. 2019 la 09:36, Elena Mihailescu via so a scris: > On Thu, 28 Mar 2019 at 14:38, Elena Mihailescu > wrote: > > > > Salutare, > > > > A doua lucrare de curs va avea loc pe 1 si 3 aprilie 2019: > > * Luni, 1 aprilie, ora 17:00, sala PR001: Seria CA + alții > > * Miercuri, 3 aprilie, ora 11:00, sala PR001: Seria CB + alții > > * Miercuri, 3 aprilie, ora 14:00, sala PR001: Seria CC + alții > > > > Lucrarea de curs va dura 10 minute, va include 3 întrebări și va > > acoperi cursurile 4, 5 și 6. Conform regulamentului [1], fiecare > > student participă la lucrare la seria din care face parte. > > > > Cererile de recorectare se vor trimite după publicarea soluțiilor pe > > wiki [2], până miercuri, 10 aprilie, ora 23:00, către Costin Carabaș > > (cu subiectul > > [SO][Lucrare X] Prenume NUME - grupa), conform regulamentului [1]. > > Salutare, > > Notele pentru a doua lucrare de curs au fost trecute în catalog, iar > soluțiile de referință au fost publicate aici [2]. Vă rugăm să le > consultați înainte de trimiterea unei eventuale cereri de recorectare. > Cererile de recorectare se vor trimite până miercuri, 10 aprilie 2019, > ora 23:00, către Costin Carabaș (cu subiectul [SO][Lucrare X] Prenume > NUME - grupa), conform regulamentului [1]. > > [1] https://ocw.cs.pub.ro/courses/so/meta/notare#lucrari_1_punct > [2]
Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV
On Mon, 15 Apr 2019 at 17:53, Mihai Barbulescu wrote: > > Salut Paul, > > Acestea nu sunt definitii oficiale > > On Mon, 15 Apr 2019 at 12:47, Paul Olaru wrote: > > > > Comportament ciudat: mă gândeam la situația în care libc și-ar reinițializa > > heap-ul după ce am dat so_exec_start și astfel bufferele din > > printf/fprintf/... nu mai sunt partajate cu programul, nu mai sunt > > flushuite corespunzător etc. Nu sunt sigur că se comportă așa sau nu, eu > > voi merge pe presupunerea asta și mă voi rezuma la a folosi doar apeluri de > > sistem pentru implementare. > > Nu te mai gandi la nimic. Daca nu e documentat in: > - manpage-ul libc-ului > - issue ridicat de developer/tester > Atunci acea problema __nu exista__ Un amendament aici: daca problema totusi exista si esti convins de ea -> se ridica bug si se specifica cum se reproduce. > > Daca nu stii sigur si ai nevoie de validarea unui > comportament/presupunere sunt doua solutii in viata reala (dar si la > temele SO) pe care le aplici: > - se face un program cat mai mic posibil de test si se valideaza sau > nu o presupunere > - se verifica documentatia daca specifica sau nu acel comportament > Asa cum faceai si la matematica metoda reducerii la absurd - > presupuneai ceva apoi gaseai contra-exemplu care sa invalideze > presupunerea. Cealalta solutie era inductia: porneai de la un caz > particular pe care il validai apoi generalizai prin presupunere prin > inductie si o validai si p-aia. > > Daca ai neclaritati asupra functionarii functiei so_start_exec din > scheletul temei 3 deschide un thread nou si pune intrebari punctuale, > cu fraze cat mai scurte si clare, iar cei care au facut scheletul vor > lamuri. > > > > > Cheaty: La tema anterioară nu puteam folosi fprintf pt a implementa > > so_fprintf -- asta ar fi fost cheaty. La SD, nu puteam folosi std::map > > pentru a implementa ceva echivalent lui. > > > > Ceea ce spui tu aici se numesc restrictii si trebuie sa tii cont de > ele in orice situatie. Nu mai folositi cuvinte complicate pentru > concepte simple. Iar presupunerea la SO este: daca nu s-a dat o > restrictie in enuntul unei teme => ai voie cu orice (asa cum i-am > clarificat lui Alice). > > Spor la lucru. > > > On Mon, Apr 15, 2019, 12:43 PM Mihai Barbulescu wrote: > >> > >> Salut, > >> > >> Iar am probleme cu vocabularul vostru si devin din nou confuz. Ce e aia: > >> - functie libc care se comporta ciudat? -> defineste conceptul > >> "comportament ciudat" ca sa imi calibrez limbajul pe frecventa ta -> > >> da-mi si exmplele la care te gandesti, eu unul nu am in minte nici o > >> functie __standard__ care se comporta ciudat. Daca exista asa ceva a > >> fost marcata ca deprecated si inlocuita! > >> - implementare in mod cheaty -> ce-i aia mod cheaty, defineste-mi? > >> Da-mi exemplu de functie care face asta > >> > >> In standarde precum libc nu se pun functii "periculoase" sau "cheaty" > >> sau whatever le numiti voi. Se pun functii care au trecut de un amplu > >> proces de review si validare. Singurul lucru de care trebuie tinut > >> cont e daca functiile sunt sau nu thread safe atunci cand programati > >> multithreaded...ATAT. Daca se comporta ca mai sus => se ridica bug cu > >> severitate mare la libc... > >> > >> Va rog sa va luati un moment de a revizui textul scris ca sa putem > >> vorbi pe aceeasi frecventa si sa fim sincronizati. > >> > >> On Mon, 15 Apr 2019 at 12:27, Paul Olaru > >> wrote: > >> > > >> > Pe scurt, dacă e o funcționalitate oferită de sistemul de operare e ok > >> > și putem folosi ce ne oferă acesta fără restricții, și tot ce e de > >> > evitat e doar folosirea funcțiilor din libc care ori s-ar comporta > >> > ciudat ori ar implementa într-un mod cheaty funcționalitatea dorită? > >> > (Notă, la tema asta nu cred că e nimic în a doua categorie dar ar putea > >> > fi câteva în prima) > >> > > >> > On Mon, Apr 15, 2019, 12:24 PM Mihai Barbulescu via so > >> > wrote: > >> >> > >> >> Buna Alice, > >> >> > >> >> Si eu sunt confuz din doua motive: > >> >> 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le > >> >> primesti in siginfo_t in si_code [1],[2] > >> >> 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si > >> >> continutul ei daca te ajuta in rezolvare, e aceasta restrictie > >> >> mentionata pe undeva? > >> >> > >> >> [1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp > >> >> [2] > >> >> https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221 > >> >> > >> >> On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so > >> >> wrote: > >> >> > > >> >> > Bună, > >> >> > > >> >> > La ce te referi mai exact? Alea nu sunt semnale. > >> >> > > >> >> > On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so > >> >> > wrote: > >> >> > > > >> >> > > Buna ziua, > >> >> > > > >> >> > > Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim > >> >> > > de semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o > >> >> > > pagina
Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV
Salut Paul, Acestea nu sunt definitii oficiale On Mon, 15 Apr 2019 at 12:47, Paul Olaru wrote: > > Comportament ciudat: mă gândeam la situația în care libc și-ar reinițializa > heap-ul după ce am dat so_exec_start și astfel bufferele din > printf/fprintf/... nu mai sunt partajate cu programul, nu mai sunt flushuite > corespunzător etc. Nu sunt sigur că se comportă așa sau nu, eu voi merge pe > presupunerea asta și mă voi rezuma la a folosi doar apeluri de sistem pentru > implementare. Nu te mai gandi la nimic. Daca nu e documentat in: - manpage-ul libc-ului - issue ridicat de developer/tester Atunci acea problema __nu exista__ Daca nu stii sigur si ai nevoie de validarea unui comportament/presupunere sunt doua solutii in viata reala (dar si la temele SO) pe care le aplici: - se face un program cat mai mic posibil de test si se valideaza sau nu o presupunere - se verifica documentatia daca specifica sau nu acel comportament Asa cum faceai si la matematica metoda reducerii la absurd - presupuneai ceva apoi gaseai contra-exemplu care sa invalideze presupunerea. Cealalta solutie era inductia: porneai de la un caz particular pe care il validai apoi generalizai prin presupunere prin inductie si o validai si p-aia. Daca ai neclaritati asupra functionarii functiei so_start_exec din scheletul temei 3 deschide un thread nou si pune intrebari punctuale, cu fraze cat mai scurte si clare, iar cei care au facut scheletul vor lamuri. > > Cheaty: La tema anterioară nu puteam folosi fprintf pt a implementa > so_fprintf -- asta ar fi fost cheaty. La SD, nu puteam folosi std::map pentru > a implementa ceva echivalent lui. > Ceea ce spui tu aici se numesc restrictii si trebuie sa tii cont de ele in orice situatie. Nu mai folositi cuvinte complicate pentru concepte simple. Iar presupunerea la SO este: daca nu s-a dat o restrictie in enuntul unei teme => ai voie cu orice (asa cum i-am clarificat lui Alice). Spor la lucru. > On Mon, Apr 15, 2019, 12:43 PM Mihai Barbulescu wrote: >> >> Salut, >> >> Iar am probleme cu vocabularul vostru si devin din nou confuz. Ce e aia: >> - functie libc care se comporta ciudat? -> defineste conceptul >> "comportament ciudat" ca sa imi calibrez limbajul pe frecventa ta -> >> da-mi si exmplele la care te gandesti, eu unul nu am in minte nici o >> functie __standard__ care se comporta ciudat. Daca exista asa ceva a >> fost marcata ca deprecated si inlocuita! >> - implementare in mod cheaty -> ce-i aia mod cheaty, defineste-mi? >> Da-mi exemplu de functie care face asta >> >> In standarde precum libc nu se pun functii "periculoase" sau "cheaty" >> sau whatever le numiti voi. Se pun functii care au trecut de un amplu >> proces de review si validare. Singurul lucru de care trebuie tinut >> cont e daca functiile sunt sau nu thread safe atunci cand programati >> multithreaded...ATAT. Daca se comporta ca mai sus => se ridica bug cu >> severitate mare la libc... >> >> Va rog sa va luati un moment de a revizui textul scris ca sa putem >> vorbi pe aceeasi frecventa si sa fim sincronizati. >> >> On Mon, 15 Apr 2019 at 12:27, Paul Olaru >> wrote: >> > >> > Pe scurt, dacă e o funcționalitate oferită de sistemul de operare e ok și >> > putem folosi ce ne oferă acesta fără restricții, și tot ce e de evitat e >> > doar folosirea funcțiilor din libc care ori s-ar comporta ciudat ori ar >> > implementa într-un mod cheaty funcționalitatea dorită? (Notă, la tema asta >> > nu cred că e nimic în a doua categorie dar ar putea fi câteva în prima) >> > >> > On Mon, Apr 15, 2019, 12:24 PM Mihai Barbulescu via so >> > wrote: >> >> >> >> Buna Alice, >> >> >> >> Si eu sunt confuz din doua motive: >> >> 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le >> >> primesti in siginfo_t in si_code [1],[2] >> >> 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si >> >> continutul ei daca te ajuta in rezolvare, e aceasta restrictie >> >> mentionata pe undeva? >> >> >> >> [1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp >> >> [2] >> >> https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221 >> >> >> >> On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so >> >> wrote: >> >> > >> >> > Bună, >> >> > >> >> > La ce te referi mai exact? Alea nu sunt semnale. >> >> > >> >> > On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so >> >> > wrote: >> >> > > >> >> > > Buna ziua, >> >> > > >> >> > > Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim >> >> > > de semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o >> >> > > pagina este mapata sau nemapata? >> >> > > >> >> > > Mulțumesc, >> >> > > Alice Suiu >> >> > > ___ >> >> > > http://ocw.cs.pub.ro/courses/so/info/lista-discutii >> >> > ___ >> >> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii >> >> >> >> >> >> >> >> -- >> >> Cu stimă, >> >> Mihai Bărbulescu >> >>
[so] [Tema3][Linux] Probleme testul 5 BSS
Salut, Intampin probleme cu testul 5, mai exact cu verificarea ca octetii care sunt in bss sunt initializati cu 0. Nu reusesc sa-mi dau seama unde anume nu setez cu 0 si ar trebui sa o fac. In principiu, calculez adresa de inceput a paginii in care se afla adresa care genereaza SIGSEGV folosind ALIGN_DOWN, aflu in care segment se afla si verific - daca este in totalitate in portiunea cuprinsa in executabil => mapez din fisierul de la offsetul corespunzator la acea adresa page_size octeti - daca este partial in executabil, partial in portiunea dintre file_size si mem_size ale segmentului => mapez din fisier doar portiunea cuprinsa in interior si restul las mapat la o zona plina cu 0 din memoria fizica - daca este in totalitate in afara fisierului => mapez adresa de inceput a paginii la un frame plin de 0 Este ok daca mapez direct fisierul la adresele virtuale? Practic tot se copiaza pana la urma in memoria fizica continutul fisierului. Daca ati putea sa va uitati peste codul urcat pe GitLab (alexandru.mihai1708), v-as fi foarte recunoscator! Numai bine, Alexandru Mihai ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV
On Mon, 15 Apr 2019 at 12:53, Alice Suiu wrote: > > Buna Mihai, > > Da imi cer scuze pentru formulare. Într-adevăr ma refeream la situația in > care ne putem folosi de orice informatie pe care ne-o oferă structura > siginfo_t pentru a vedea dacă o pagina este mapata sau nu. E OK, am vrut sa ma lamuresc > > Nu am vazut nicio restricție in acest sens, însă am zis sa intreb ca sa fiu > sigura ca implementarea mea este corecta. Daca nu sunt restrictii explicite puse in enunt va rog sa tineti minte ca inseamna ca AVETI VOIE sa faceti acel lucru. Default is: you're allowed unless otherwise advised. > > Mulțumesc pentru răspuns. Cu placere > Alice > > > On Apr 2019, at 12:24, Mihai Barbulescu wrote: > > > > Buna Alice, > > > > Si eu sunt confuz din doua motive: > > 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le > > primesti in siginfo_t in si_code [1],[2] > > 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si > > continutul ei daca te ajuta in rezolvare, e aceasta restrictie > > mentionata pe undeva? > > > > [1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp > > [2] > > https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221 > > > > On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so > > wrote: > >> > >> Bună, > >> > >> La ce te referi mai exact? Alea nu sunt semnale. > >> > >>> On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so > >>> wrote: > >>> > >>> Buna ziua, > >>> > >>> Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim de > >>> semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o pagina este > >>> mapata sau nemapata? > >>> > >>> Mulțumesc, > >>> Alice Suiu > >>> ___ > >>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii > >> ___ > >> http://ocw.cs.pub.ro/courses/so/info/lista-discutii > > > > > > > > -- > > Cu stimă, > > Mihai Bărbulescu -- Cu stimă, Mihai Bărbulescu ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [Tema3][Linux] fisier executabil
Da, de-aia si avem depunctare daca nu folosesti static la globala interna unui modul. Problema cu multe accese la o globala si complicarea procesului din cauza asta este o non-problema. Doar un amator ar scrie cod cu side effects si accese aiurea la o globala. Mai exista si variabilele extern si nu vad nici o problema in a le folosi indiferent de dimensiunea codebase-ului __daca ele au sens__ in contextul dat. Legat de goto statements am uitat sa vi-l recomand pe Knuth: http://cowboyprogramming.com/files/p261-knuth.pdf On Mon, 15 Apr 2019 at 12:43, Paul Olaru wrote: > > Globalele sunt o problemă în proiectele mari pentru că este mai dificil să > vezi ce cod le folosește. Și pentru majoritatea situațiilor la care mă > gândesc (INCLUSIV cea din tema asta) mă gândesc că o variabilă globală > limitată (sau statică per clasă) este suficient -- elimină problema efectelor > secundare fără a îngreuna utilizarea codului în sine. Mai ales că suntem > single threaded și nu e nevoie nici măcar de sincronizare, în situația de > față variabilele globale (cu static) sunt chiar ok. Recomand 'static' acolo > pentru ca alte module să nu modifice imprevizibil variabila. > > Un global global fără nicio restricție e ok în proiecte până în 1000-2000 de > linii după părerea mea (sau proiecte mai mari dacă e mult boilerplate; ideea > e ca întregul cod să încapă în mintea unei singure persoane) dar în acelea > care sunt mai mari, sau vor deveni pe viitor mai mari, pot deveni o problemă > dacă le folosești fără un motiv bun. Zic că complică procesul de debug pentru > că există posibilitatea să existe multe accese la aceeași variabilă globală. > Soluția cu 'static' rezolvă chestia asta în cele mai multe situații -- > rareori e o restricție reală. > > On Mon, Apr 15, 2019, 12:36 PM Mihai Barbulescu via so > wrote: >> >> Salutare tuturor, >> >> In completarea maestrului RD eu unul chiar incurajez in situatii >> extreme/in situatii in care nu se pot evita atat folosirea goto cat si >> folosirea variabilelor globale. >> >> Exemple de folosire a variabilelor globale pe langa cel de care tocmai >> v-ati lovit (si este OK si __IN REGULA__ sa folositi globala) ar fi sa >> aveti un state machine asupra caruia umbla mai multe threaduri (sau >> nu) - de ex pt a stii starea curenta (daca ai threaduri faci accesul >> "sincronizat"). >> >> Un exemplu de folosire goto aveti chiar pe wiki pentru eliberarea >> resurselor [1]. Acest approach e foarte important in lucrul cu >> dispozitive embedded pentru ca puteti lasa intregi resurse hardware >> marcate ca "ocupate" aiurea >> >> Paul Olaru: as vrea si o justificare pentru afirmatia "E bine să nu ai >> mai multe globale decât este necesar (complică mult procesul de >> debug)." - ce inseamna ca procesul de debug e complicat? Debuggerul >> stie sa arate si variabilele globale, de-aia fiecare proces are acea >> zona de memorie pt globale (.data si .bss) si poti debuga continutul >> lor prin breakpoint si inspectand acele zone de memorie ca sa fii >> sigur. E complicat procesul de debug ca trebuie sa te uiti in "inca o >> zona de memorie"? Raspunsul meu e NU, asta vine doar din >> lene/necunoastere. >> Stiu paper-ul la care te gandesti - ca sa nu ai side effects sau alte >> probleme de care zice acolo inseamna doar sa scrii codul cu ceva mai >> multa grija, lucru care oricum ar trebui sa va intre in reflex. >> >> Ah, da, la SD daca aveti de implementat lucrul pe o lista inlantuita >> si declarati o globala pt structura lista inlantuita ca sa scrieti >> functii cu cat mai putini parametrii sunteti noobs, de-aia va >> interzice la SD sa faceti asemenea abominatii. Dar este, asa cum a zis >> RD, o recomandare/guideline care admite exceptii. >> >> Sper c-am reusit sa demontez fake news-ul conform caruia globalele >> sunt diavolul pe pamantSunt o unealta asa cum e si tesla si >> trebuie sa ai grija sa nu iti dai cu ea in ... stiti voi continuarea. >> >> [1] https://ocw.cs.pub.ro/courses/so/laboratoare/resurse/die#alta_abordare >> >> >> >> On Sun, 14 Apr 2019 at 22:59, Razvan Deaconescu via so >> wrote: >> > >> > "Alexandru-Ionuţ MÎNDRU (87849)" via so writes: >> > > Eu cel puțin știu de la PC/SD din anul 1, nu mai știu exact care >> > > dintre cele 2. Era regula pentru teme să nu se folosească variabile >> > > globale, se scădea puncte pe treaba asta, fără a se explica de ce e >> > > greșit sau de ce să nu le folosim. >> > >> > Well, there's your problem. >> > >> > > Chiar și acum la tema 1 la PC spre exemplu, există această regulă. >> > >> > O să discutăm cu cei de acolo. >> > >> > > Cei drept acum nu am verificat strict pentru SO dacă există această >> > > regulă, dar am rămas cu acest lucru și presupun că și alții. >> > >> > Există reguli și există recomandări. Regulile sunt foarte puține (citat >> > aproximativ Jack Sparrow). În dezvoltarea aplicațiilor sunt foarte >> > puține "golden rules". Luați recomandările, țineți-vă de ele, dar >> > admiteți când e o prostie să te ții de
Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV
Buna Mihai, Da imi cer scuze pentru formulare. Într-adevăr ma refeream la situația in care ne putem folosi de orice informatie pe care ne-o oferă structura siginfo_t pentru a vedea dacă o pagina este mapata sau nu. Nu am vazut nicio restricție in acest sens, însă am zis sa intreb ca sa fiu sigura ca implementarea mea este corecta. Mulțumesc pentru răspuns. Alice > On Apr 2019, at 12:24, Mihai Barbulescu wrote: > > Buna Alice, > > Si eu sunt confuz din doua motive: > 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le > primesti in siginfo_t in si_code [1],[2] > 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si > continutul ei daca te ajuta in rezolvare, e aceasta restrictie > mentionata pe undeva? > > [1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp > [2] > https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221 > > On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so > wrote: >> >> Bună, >> >> La ce te referi mai exact? Alea nu sunt semnale. >> >>> On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so >>> wrote: >>> >>> Buna ziua, >>> >>> Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim de >>> semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o pagina este >>> mapata sau nemapata? >>> >>> Mulțumesc, >>> Alice Suiu >>> ___ >>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii >> ___ >> http://ocw.cs.pub.ro/courses/so/info/lista-discutii > > > > -- > Cu stimă, > Mihai Bărbulescu ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV
Comportament ciudat: mă gândeam la situația în care libc și-ar reinițializa heap-ul după ce am dat so_exec_start și astfel bufferele din printf/fprintf/... nu mai sunt partajate cu programul, nu mai sunt flushuite corespunzător etc. Nu sunt sigur că se comportă așa sau nu, eu voi merge pe presupunerea asta și mă voi rezuma la a folosi doar apeluri de sistem pentru implementare. Cheaty: La tema anterioară nu puteam folosi fprintf pt a implementa so_fprintf -- asta ar fi fost cheaty. La SD, nu puteam folosi std::map pentru a implementa ceva echivalent lui. On Mon, Apr 15, 2019, 12:43 PM Mihai Barbulescu wrote: > Salut, > > Iar am probleme cu vocabularul vostru si devin din nou confuz. Ce e aia: > - functie libc care se comporta ciudat? -> defineste conceptul > "comportament ciudat" ca sa imi calibrez limbajul pe frecventa ta -> > da-mi si exmplele la care te gandesti, eu unul nu am in minte nici o > functie __standard__ care se comporta ciudat. Daca exista asa ceva a > fost marcata ca deprecated si inlocuita! > - implementare in mod cheaty -> ce-i aia mod cheaty, defineste-mi? > Da-mi exemplu de functie care face asta > > In standarde precum libc nu se pun functii "periculoase" sau "cheaty" > sau whatever le numiti voi. Se pun functii care au trecut de un amplu > proces de review si validare. Singurul lucru de care trebuie tinut > cont e daca functiile sunt sau nu thread safe atunci cand programati > multithreaded...ATAT. Daca se comporta ca mai sus => se ridica bug cu > severitate mare la libc... > > Va rog sa va luati un moment de a revizui textul scris ca sa putem > vorbi pe aceeasi frecventa si sa fim sincronizati. > > On Mon, 15 Apr 2019 at 12:27, Paul Olaru > wrote: > > > > Pe scurt, dacă e o funcționalitate oferită de sistemul de operare e ok > și putem folosi ce ne oferă acesta fără restricții, și tot ce e de evitat e > doar folosirea funcțiilor din libc care ori s-ar comporta ciudat ori ar > implementa într-un mod cheaty funcționalitatea dorită? (Notă, la tema asta > nu cred că e nimic în a doua categorie dar ar putea fi câteva în prima) > > > > On Mon, Apr 15, 2019, 12:24 PM Mihai Barbulescu via so < > so@cursuri.cs.pub.ro> wrote: > >> > >> Buna Alice, > >> > >> Si eu sunt confuz din doua motive: > >> 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le > >> primesti in siginfo_t in si_code [1],[2] > >> 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si > >> continutul ei daca te ajuta in rezolvare, e aceasta restrictie > >> mentionata pe undeva? > >> > >> [1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp > >> [2] > https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221 > >> > >> On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so > >> wrote: > >> > > >> > Bună, > >> > > >> > La ce te referi mai exact? Alea nu sunt semnale. > >> > > >> > On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so > wrote: > >> > > > >> > > Buna ziua, > >> > > > >> > > Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim > de semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o pagina > este mapata sau nemapata? > >> > > > >> > > Mulțumesc, > >> > > Alice Suiu > >> > > ___ > >> > > http://ocw.cs.pub.ro/courses/so/info/lista-discutii > >> > ___ > >> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii > >> > >> > >> > >> -- > >> Cu stimă, > >> Mihai Bărbulescu > >> ___ > >> http://ocw.cs.pub.ro/courses/so/info/lista-discutii > > > > -- > Cu stimă, > Mihai Bărbulescu > ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV
Salut, Iar am probleme cu vocabularul vostru si devin din nou confuz. Ce e aia: - functie libc care se comporta ciudat? -> defineste conceptul "comportament ciudat" ca sa imi calibrez limbajul pe frecventa ta -> da-mi si exmplele la care te gandesti, eu unul nu am in minte nici o functie __standard__ care se comporta ciudat. Daca exista asa ceva a fost marcata ca deprecated si inlocuita! - implementare in mod cheaty -> ce-i aia mod cheaty, defineste-mi? Da-mi exemplu de functie care face asta In standarde precum libc nu se pun functii "periculoase" sau "cheaty" sau whatever le numiti voi. Se pun functii care au trecut de un amplu proces de review si validare. Singurul lucru de care trebuie tinut cont e daca functiile sunt sau nu thread safe atunci cand programati multithreaded...ATAT. Daca se comporta ca mai sus => se ridica bug cu severitate mare la libc... Va rog sa va luati un moment de a revizui textul scris ca sa putem vorbi pe aceeasi frecventa si sa fim sincronizati. On Mon, 15 Apr 2019 at 12:27, Paul Olaru wrote: > > Pe scurt, dacă e o funcționalitate oferită de sistemul de operare e ok și > putem folosi ce ne oferă acesta fără restricții, și tot ce e de evitat e doar > folosirea funcțiilor din libc care ori s-ar comporta ciudat ori ar implementa > într-un mod cheaty funcționalitatea dorită? (Notă, la tema asta nu cred că e > nimic în a doua categorie dar ar putea fi câteva în prima) > > On Mon, Apr 15, 2019, 12:24 PM Mihai Barbulescu via so > wrote: >> >> Buna Alice, >> >> Si eu sunt confuz din doua motive: >> 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le >> primesti in siginfo_t in si_code [1],[2] >> 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si >> continutul ei daca te ajuta in rezolvare, e aceasta restrictie >> mentionata pe undeva? >> >> [1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp >> [2] >> https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221 >> >> On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so >> wrote: >> > >> > Bună, >> > >> > La ce te referi mai exact? Alea nu sunt semnale. >> > >> > On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so >> > wrote: >> > > >> > > Buna ziua, >> > > >> > > Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim de >> > > semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o pagina >> > > este mapata sau nemapata? >> > > >> > > Mulțumesc, >> > > Alice Suiu >> > > ___ >> > > http://ocw.cs.pub.ro/courses/so/info/lista-discutii >> > ___ >> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii >> >> >> >> -- >> Cu stimă, >> Mihai Bărbulescu >> ___ >> http://ocw.cs.pub.ro/courses/so/info/lista-discutii -- Cu stimă, Mihai Bărbulescu ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [Tema3][Linux] fisier executabil
Globalele sunt o problemă în proiectele mari pentru că este mai dificil să vezi ce cod le folosește. Și pentru majoritatea situațiilor la care mă gândesc (INCLUSIV cea din tema asta) mă gândesc că o variabilă globală limitată (sau statică per clasă) este suficient -- elimină problema efectelor secundare fără a îngreuna utilizarea codului în sine. Mai ales că suntem single threaded și nu e nevoie nici măcar de sincronizare, în situația de față variabilele globale (cu static) sunt chiar ok. Recomand 'static' acolo pentru ca alte module să nu modifice imprevizibil variabila. Un global global fără nicio restricție e ok în proiecte până în 1000-2000 de linii după părerea mea (sau proiecte mai mari dacă e mult boilerplate; ideea e ca întregul cod să încapă în mintea unei singure persoane) dar în acelea care sunt mai mari, sau vor deveni pe viitor mai mari, pot deveni o problemă dacă le folosești fără un motiv bun. Zic că complică procesul de debug pentru că există posibilitatea să existe multe accese la aceeași variabilă globală. Soluția cu 'static' rezolvă chestia asta în cele mai multe situații -- rareori e o restricție reală. On Mon, Apr 15, 2019, 12:36 PM Mihai Barbulescu via so wrote: > Salutare tuturor, > > In completarea maestrului RD eu unul chiar incurajez in situatii > extreme/in situatii in care nu se pot evita atat folosirea goto cat si > folosirea variabilelor globale. > > Exemple de folosire a variabilelor globale pe langa cel de care tocmai > v-ati lovit (si este OK si __IN REGULA__ sa folositi globala) ar fi sa > aveti un state machine asupra caruia umbla mai multe threaduri (sau > nu) - de ex pt a stii starea curenta (daca ai threaduri faci accesul > "sincronizat"). > > Un exemplu de folosire goto aveti chiar pe wiki pentru eliberarea > resurselor [1]. Acest approach e foarte important in lucrul cu > dispozitive embedded pentru ca puteti lasa intregi resurse hardware > marcate ca "ocupate" aiurea > > Paul Olaru: as vrea si o justificare pentru afirmatia "E bine să nu ai > mai multe globale decât este necesar (complică mult procesul de > debug)." - ce inseamna ca procesul de debug e complicat? Debuggerul > stie sa arate si variabilele globale, de-aia fiecare proces are acea > zona de memorie pt globale (.data si .bss) si poti debuga continutul > lor prin breakpoint si inspectand acele zone de memorie ca sa fii > sigur. E complicat procesul de debug ca trebuie sa te uiti in "inca o > zona de memorie"? Raspunsul meu e NU, asta vine doar din > lene/necunoastere. > Stiu paper-ul la care te gandesti - ca sa nu ai side effects sau alte > probleme de care zice acolo inseamna doar sa scrii codul cu ceva mai > multa grija, lucru care oricum ar trebui sa va intre in reflex. > > Ah, da, la SD daca aveti de implementat lucrul pe o lista inlantuita > si declarati o globala pt structura lista inlantuita ca sa scrieti > functii cu cat mai putini parametrii sunteti noobs, de-aia va > interzice la SD sa faceti asemenea abominatii. Dar este, asa cum a zis > RD, o recomandare/guideline care admite exceptii. > > Sper c-am reusit sa demontez fake news-ul conform caruia globalele > sunt diavolul pe pamantSunt o unealta asa cum e si tesla si > trebuie sa ai grija sa nu iti dai cu ea in ... stiti voi continuarea. > > [1] https://ocw.cs.pub.ro/courses/so/laboratoare/resurse/die#alta_abordare > > > > On Sun, 14 Apr 2019 at 22:59, Razvan Deaconescu via so > wrote: > > > > "Alexandru-Ionuţ MÎNDRU (87849)" via so writes: > > > Eu cel puțin știu de la PC/SD din anul 1, nu mai știu exact care > > > dintre cele 2. Era regula pentru teme să nu se folosească variabile > > > globale, se scădea puncte pe treaba asta, fără a se explica de ce e > > > greșit sau de ce să nu le folosim. > > > > Well, there's your problem. > > > > > Chiar și acum la tema 1 la PC spre exemplu, există această regulă. > > > > O să discutăm cu cei de acolo. > > > > > Cei drept acum nu am verificat strict pentru SO dacă există această > > > regulă, dar am rămas cu acest lucru și presupun că și alții. > > > > Există reguli și există recomandări. Regulile sunt foarte puține (citat > > aproximativ Jack Sparrow). În dezvoltarea aplicațiilor sunt foarte > > puține "golden rules". Luați recomandările, țineți-vă de ele, dar > > admiteți când e o prostie să te ții de ele cu dinții doar pentru că "așa > > e bine". > > > > Exemple de recomandări, nu reguli, au excepții > > > > * Nu folosiți variabile globale. > > > > * Nu folosiți goto. > > > > * Puneți funcțiile deasupra main-ului. > > > > * Folosiți thread-uri, operații asincrone, expresii regulate, semnale. > > > > * Faceți codul portabil. > > > > Exemple de reguli sau lucruri care sunt mereu bune (nu știu să aibă > > excepții în afara unor concursuri de genul "Obfuscated C contest"). > > > > * Să fie codul consecvent. Prost dar consecvent prost decât bine în n > > feluri. > > > > * Variabile și funcții denumite cu cap, nu tmp_var, do_stuff, my_var. > > > > * Defensive programming: "Always code as if
Re: [so] [Tema3][Linux] fisier executabil
Salutare tuturor, In completarea maestrului RD eu unul chiar incurajez in situatii extreme/in situatii in care nu se pot evita atat folosirea goto cat si folosirea variabilelor globale. Exemple de folosire a variabilelor globale pe langa cel de care tocmai v-ati lovit (si este OK si __IN REGULA__ sa folositi globala) ar fi sa aveti un state machine asupra caruia umbla mai multe threaduri (sau nu) - de ex pt a stii starea curenta (daca ai threaduri faci accesul "sincronizat"). Un exemplu de folosire goto aveti chiar pe wiki pentru eliberarea resurselor [1]. Acest approach e foarte important in lucrul cu dispozitive embedded pentru ca puteti lasa intregi resurse hardware marcate ca "ocupate" aiurea Paul Olaru: as vrea si o justificare pentru afirmatia "E bine să nu ai mai multe globale decât este necesar (complică mult procesul de debug)." - ce inseamna ca procesul de debug e complicat? Debuggerul stie sa arate si variabilele globale, de-aia fiecare proces are acea zona de memorie pt globale (.data si .bss) si poti debuga continutul lor prin breakpoint si inspectand acele zone de memorie ca sa fii sigur. E complicat procesul de debug ca trebuie sa te uiti in "inca o zona de memorie"? Raspunsul meu e NU, asta vine doar din lene/necunoastere. Stiu paper-ul la care te gandesti - ca sa nu ai side effects sau alte probleme de care zice acolo inseamna doar sa scrii codul cu ceva mai multa grija, lucru care oricum ar trebui sa va intre in reflex. Ah, da, la SD daca aveti de implementat lucrul pe o lista inlantuita si declarati o globala pt structura lista inlantuita ca sa scrieti functii cu cat mai putini parametrii sunteti noobs, de-aia va interzice la SD sa faceti asemenea abominatii. Dar este, asa cum a zis RD, o recomandare/guideline care admite exceptii. Sper c-am reusit sa demontez fake news-ul conform caruia globalele sunt diavolul pe pamantSunt o unealta asa cum e si tesla si trebuie sa ai grija sa nu iti dai cu ea in ... stiti voi continuarea. [1] https://ocw.cs.pub.ro/courses/so/laboratoare/resurse/die#alta_abordare On Sun, 14 Apr 2019 at 22:59, Razvan Deaconescu via so wrote: > > "Alexandru-Ionuţ MÎNDRU (87849)" via so writes: > > Eu cel puțin știu de la PC/SD din anul 1, nu mai știu exact care > > dintre cele 2. Era regula pentru teme să nu se folosească variabile > > globale, se scădea puncte pe treaba asta, fără a se explica de ce e > > greșit sau de ce să nu le folosim. > > Well, there's your problem. > > > Chiar și acum la tema 1 la PC spre exemplu, există această regulă. > > O să discutăm cu cei de acolo. > > > Cei drept acum nu am verificat strict pentru SO dacă există această > > regulă, dar am rămas cu acest lucru și presupun că și alții. > > Există reguli și există recomandări. Regulile sunt foarte puține (citat > aproximativ Jack Sparrow). În dezvoltarea aplicațiilor sunt foarte > puține "golden rules". Luați recomandările, țineți-vă de ele, dar > admiteți când e o prostie să te ții de ele cu dinții doar pentru că "așa > e bine". > > Exemple de recomandări, nu reguli, au excepții > > * Nu folosiți variabile globale. > > * Nu folosiți goto. > > * Puneți funcțiile deasupra main-ului. > > * Folosiți thread-uri, operații asincrone, expresii regulate, semnale. > > * Faceți codul portabil. > > Exemple de reguli sau lucruri care sunt mereu bune (nu știu să aibă > excepții în afara unor concursuri de genul "Obfuscated C contest"). > > * Să fie codul consecvent. Prost dar consecvent prost decât bine în n > feluri. > > * Variabile și funcții denumite cu cap, nu tmp_var, do_stuff, my_var. > > * Defensive programming: "Always code as if the guy who ends up > maintaining your code will be a violent psychopath who knows where you > live". > > * Trecut codul prin verificatoare statice și dinamice. > > * Făcut recenzie la cod. > > Răzvan > ___ > http://ocw.cs.pub.ro/courses/so/info/lista-discutii -- Cu stimă, Mihai Bărbulescu ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV
Pe scurt, dacă e o funcționalitate oferită de sistemul de operare e ok și putem folosi ce ne oferă acesta fără restricții, și tot ce e de evitat e doar folosirea funcțiilor din libc care ori s-ar comporta ciudat ori ar implementa într-un mod cheaty funcționalitatea dorită? (Notă, la tema asta nu cred că e nimic în a doua categorie dar ar putea fi câteva în prima) On Mon, Apr 15, 2019, 12:24 PM Mihai Barbulescu via so wrote: > Buna Alice, > > Si eu sunt confuz din doua motive: > 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le > primesti in siginfo_t in si_code [1],[2] > 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si > continutul ei daca te ajuta in rezolvare, e aceasta restrictie > mentionata pe undeva? > > [1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp > [2] > https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221 > > On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so > wrote: > > > > Bună, > > > > La ce te referi mai exact? Alea nu sunt semnale. > > > > On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so > wrote: > > > > > > Buna ziua, > > > > > > Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim de > semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o pagina este > mapata sau nemapata? > > > > > > Mulțumesc, > > > Alice Suiu > > > ___ > > > http://ocw.cs.pub.ro/courses/so/info/lista-discutii > > ___ > > http://ocw.cs.pub.ro/courses/so/info/lista-discutii > > > > -- > Cu stimă, > Mihai Bărbulescu > ___ > http://ocw.cs.pub.ro/courses/so/info/lista-discutii ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV
Buna Alice, Si eu sunt confuz din doua motive: 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le primesti in siginfo_t in si_code [1],[2] 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si continutul ei daca te ajuta in rezolvare, e aceasta restrictie mentionata pe undeva? [1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp [2] https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221 On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so wrote: > > Bună, > > La ce te referi mai exact? Alea nu sunt semnale. > > On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so wrote: > > > > Buna ziua, > > > > Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim de > > semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o pagina este > > mapata sau nemapata? > > > > Mulțumesc, > > Alice Suiu > > ___ > > http://ocw.cs.pub.ro/courses/so/info/lista-discutii > ___ > http://ocw.cs.pub.ro/courses/so/info/lista-discutii -- Cu stimă, Mihai Bărbulescu ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV
Bună, La ce te referi mai exact? Alea nu sunt semnale. On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so wrote: > > Buna ziua, > > Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim de > semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o pagina este > mapata sau nemapata? > > Mulțumesc, > Alice Suiu > ___ > http://ocw.cs.pub.ro/courses/so/info/lista-discutii ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
[so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV
Buna ziua, Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim de semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o pagina este mapata sau nemapata? Mulțumesc, Alice Suiu ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
