.:: Jorge Pereira ::.

"UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity."

Browsing Posts published by jpereira

Some of the true craftsmanship in the world we take for granted. One of these things is the common tools on Linux, like ps and ls. Even though the commands might be perceived as simple, there is more to it when looking under the hood. This is where ELF or the Executable and Linkable Format comes in. A file format that used a lot, yet truly understood by only a few. Let’s get this understanding with this introduction tutorial!

More here.

Good explanations to have successful with GIT branching model.

git-model@2x

The Infamous Windows “Hello World” Program (A good and archaeological post by Petzold)

ProgRefPg13

seven years!

No comments

Even through times of high and low with the published post… here we are!! today, is a birthday of my blog, we seven years of life!! =]

Aconteceu no último dia 25 de maio o 10° Encontro de Programadores de C & C++, o evento foi muito bacana e contou com uma grade de palestras bem diversificada. abaixo segue lista completa de todas as palestras e os devidos artigos e materiais utilizados pelos palestrantes!

C/C++ Brasil

Explorando Windows 32 em Windows 64 — Fernando Roberto da Silva
Um sistema operacional Windows de 64 bits é capaz de executar programas de 32 bits de forma completamente transparente, mas para alguns, isso pode gerar comportamentos inesperados. Este artigo descreve de maneira prática como o Windows é capaz de realizar essa tarefa de forma a permitir que programas de 32 bits possam coexistir com programas de 64 bits, explicando tais estranhezas e justificando-as. Como drivers de kernel se encaixam nessa história e quais os possíveis problemas podem ser observados na migração de drivers 32 bits para 64 bits.
  
Programação em GPU utilizando OpenCL — André Tupinambá
O OpenCL é um padrão aberto, definido pelo Khronos Group, para programação em dispositivo genérico. Hoje ele é suportado pelos principais fornecedores de GPUs (Nvidia, AMD e, recentemente, Intel) e CPUs (Intel, AMD e IBM); e espera-se que outros processadores tenham suporte em breve, pois já existem chips para celulares homologados, como o CPU ARMv7 com Mali-T604 GPU, e outros chips, como o FPGA da empresa Altera, em desenvolvimento. O framework OpenCL é composto por uma linguagem, uma API, bibliotecas e um sistema de suporte para o desenvolvimento. A linguagem é baseada no padrão C99 com algumas extensões para suportar os modelos de memória e execução do OpenCL. Este artigo descreve o que é programação para GPU e apresenta a plataforma OpenCL, com um estudo de caso.

Interoperando C++ e Java usando meta-programação em C++ — Felipe Magno de Almeida
Construção de middlewares baseados na tecnologia Java exigem por muitas vezes a interação com recursos específicos da plataforma, interagindo normalmente com interfaces em linguagem C ou C++. Essas interações com código nativo precisam ser feitas através da Java Native Interface na implementação OpenJDK do Java, que trás diversas dificuldades para o programador e tornam a tarefa de desenvolvimento desnecessariamente árdua, e o resultado dificilmente livre de bugs. Abordarei sobre o uso e construção de uma biblioteca que ajudará o usuário a mitigar os problemas decorrentes do uso direto da Java Native Interface e será feita uma comparação dessa biblioteca com outras soluções de binding como as bibliotecas luabind e Boost.Python, assim como suas diferenças intrínsecas por conta da tipagem estática da linguagem Java.

Kernel Insecurity Vectors — Carlos Carvalho e Alan Silva
O estudo das falhas de segurança pode ser tão geral quanto um buffer overflow em qualquer programa ou tão específico quanto defeitos na implementação do módulo X na versão Y da máquina virtual Z do fabricante W. Neste trabalho demonstramos falhas de segurança e métodos de exploração no kernel do Linux, mostrando a arquitetura e revisando algumas técnicas já conhecidas, para com isso tentar encontrar um caminho que resulte em novos métodos para explorar essas falhas, que chamamos vetores de exploração.

Durante esses dias discutindo com um amigo sobre o acesso a memoria de forma atômica, e durante alguns testes e provas de conceito surgiram alguns problemas devido ao esquema de synchronize ser um recurso dependente da plataforma e compilador.

Como a chamada __sync_synchronize() e nativa no compilador, e dependendo da versão não vai estar disponivel. segue abaixo uma solução:

Contornando o Problema

#include <stdio.h>

#ifdef NO_SYNC_SYNCHRONIZE
#warning "Ops! Don't have native __sync_synchronize(), using the asm hardcode."
#    define __sync_synchronize() __asm__ __volatile__ ( "rep;nop": : :"memory" );
#endif

#define my__sync_synchronize() __sync_synchronize()

int
main ()
{
    int foo = 0;

    printf ("Trecho abaixo será atômico!\n");
    foo = 0xd34db33f;
    my__sync_synchronize ();

    return 0;
}

* Levando em consideração o uso sobre a plataforma x86.

Mais sobre o assunto.