Re: gcc books, gcc debug (errata)

2018-09-04 Thread Paul Koning



> On Sep 4, 2018, at 12:40 PM, gérard Calliet  
> wrote:
> 
> (our build version is 4.7.3)
> 
> Hello,
> 
> I'm just a beginner in gcc. (I contributed to the rebuild of the gnat ada 
> compiler (version 3.4.7) on OpenVMS last year: 
> https://github.com/AdaLabs/gnat-vms).
> 
> As I do love books and encyclopedic learning attitude, I searched for a good 
> book about gcc.

My favorite resource is the GCC Internals manual, which is part of the GCC 
distribution.  Unlike the internals manuals from some other GNU projects, it's 
quite thorough.  Not everything is covered deep enough, but it certainly 
delivers a solid basis on many aspects of the system.

paul




gcc books, gcc debug (errata)

2018-09-04 Thread gérard Calliet

(our build version is 4.7.3)

Hello,

I'm just a beginner in gcc. (I contributed to the rebuild of the gnat 
ada compiler (version 3.4.7) on OpenVMS last year: 
https://github.com/AdaLabs/gnat-vms).


As I do love books and encyclopedic learning attitude, I searched for a 
good book about gcc.


I found this reference: Source Code Anaysis of GCC, Lixiang Yang. But it 
seems it is out of print. Is there someone who could sell me one?


By the way my interests on gcc now are about the debug machinery (in my 
version 3.4.7, or something like that). Every information or synthesis 
about that very wellcomed.


Thanks,

Gérard Calliet, pia-sofer Paris



gcc books, gcc debug

2018-09-04 Thread gérard Calliet

Hello,

I'm just a beginner in gcc. (I contributed to the rebuild of the gnat 
ada compiler (version 3.4.7) on OpenVMS last year: 
https://github.com/AdaLabs/gnat-vms).


As I do love books and encyclopedic learning attitude, I searched for a 
good book about gcc.


I found this reference: Source Code Anaysis of GCC, Lixiang Yang. But it 
seems it is out of print. Is there someone who could sell me one?


By the way my interests on gcc now are about the debug machinery (in my 
version 3.4.7, or something like that). Every information or synthesis 
about that very wellcomed.


Thanks,

Gérard Calliet, pia-sofer Paris



Hotel room available for GNU Tools Cauldron

2018-09-04 Thread Jeremy Bennett
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

One attendee has had to drop out at short notice but has already
booked a hotel room from Thursday to Monday.

If you are a student or other impecunious attendee of the GNU Tools
Cauldron who would like to take advantage of this room, please send me
an email ASAP and we will arrange to transfer it to you.

Best wishes,


Jeremy

- -- 
Tel: +44 (1590) 610184
Cell:+44 (7970) 676050
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email:   jeremy.benn...@embecosm.com
Web: www.embecosm.com
PGP key: 1024D/BEF58172FB4754E1 2009-03-20
-BEGIN PGP SIGNATURE-

iEYEARECAAYFAluOY64ACgkQvvWBcvtHVOFF9ACdEJ6Q0Up1UJJ6Q0VUpHhiKZm2
a5wAoI3GMIZdV+dWIYyBxre1o3KdEHJ0
=9vEZ
-END PGP SIGNATURE-


LRA Vs match_scratch

2018-09-04 Thread Claudiu Zissulescu
Hi guys,

I am trying to get LRA fully working for ARC, but I've got an issue.
Whenever, LRA analyses an instruction having (clobber
(match_scratch:SI 3 "=X, ...)) in its pattern I hit the assert in
lra-constraints.c:4101, and it seems it has to do with the scratch's
'X' constraint.
Do I miss something? Is there any limitation between LRA and scratch
operands having in their alternative 'X' constraint?

Any help appreciated,
Claudiu


Call for Presentations on Secure Compilation (PriSC Workshop @ POPL'19)

2018-09-04 Thread Dominique Devriese
(apologies if you receive multiple copies of this announcement)

===
Call for Presentations on Secure Compilation (PriSC Workshop @ POPL'19)
===

The emerging field of secure compilation aims to preserve security
properties of programs when they have been compiled to low-level languages
such as assembly, where high-level abstractions don’t exist, and unsafe,
unexpected interactions with libraries, other programs, the operating
system and even the hardware are possible.
For unsafe source languages like C, secure compilation requires careful
handling of undefined source-language behavior (like buffer overflows and
double frees).
Formally, secure compilation aims to protect high-level language
abstractions in compiled code, even against adversarial low-level contexts,
thus enabling sound reasoning about security in the source language.
A complementary goal is to keep the compiled code efficient, often
leveraging new hardware security features and advances in compiler design.
Other necessary components are identifying and formalizing properties that
secure compilers must possess, devising efficient security mechanisms (both
software and hardware), and developing effective verification and proof
techniques.
Research in the field thus puts together advances in compiler design,
programming languages, systems security, verification, and computer
architecture.

=
3rd Workshop on Principles of Secure Compilation (PriSC 2019)
=

The Workshop on Principles of Secure Compilation (PriSC) is a relatively
new, informal 1-day workshop without any proceedings.
The goal is to bring together researchers interested in secure compilation
and to identify interesting research directions and open challenges.

The 3rd edition of PriSC will be held in Lisbon, together with the ACM
SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL),
2019.
The exact date will be either January 13 or January 19 (to be decided by
the POPL organizers).

More information is available at http://popl19.sigplan.org/track/prisc-2019
Important Dates
* Presentation proposal submission deadline: 17 October 2018, AoE
* Presentation proposal notification: 10 November 2018
* PriSC Workshop takes place: either Sunday, 13 January 2019 or Saturday 19
January 2019 (to be decided by the POPL organizers)

=
Presentation Proposals and Attending the Workshop
=

Anyone interested in presenting at the workshop should submit an extended
abstract (up to 2 pages, details below) covering past, ongoing, or future
work.
Any topic that could be of interest to secure compilation is in scope.
Secure compilation should be interpreted very broadly to include any work
in security, programming languages, architecture, systems or their
combination that can be leveraged to preserve security properties of
programs when they are compiled or to eliminate low-level vulnerabilities.
Presentations that provide a useful outside view or challenge the community
are also welcome.
This includes presentations on new attack vectors such as
microarchitectural side-channels, whose defenses could benefit from
compiler techniques.

Specific topics of interest include but are not limited to:
* attacker models for secure compiler chains.
* secure compiler properties: fully abstract compilation and similar
properties, memory safety, control-flow integrity, preservation of safety,
information flow and other (hyper-)properties against adversarial contexts,
secure multi-language interoperability.
* secure interaction between different programming languages: foreign
function interfaces, gradual types, securely combining different memory
management strategies.
* enforcement mechanisms and low-level security primitives: static
checking, program verification, typed assembly languages, reference
monitoring, program rewriting, software-based isolation/hiding techniques
(SFI, crypto-based, randomization-based, OS/hypervisor-based),
security-oriented architectural features such as Intel’s SGX, MPX and MPK,
capability machines, side-channel defenses, object capabilities.
* experimental evaluation and applications of secure compilers.
* proof methods relevant to compilation: (bi)simulation, logical relations,
game semantics, trace semantics, multi-language semantics, embedded
interpreters.
* formal verification of secure compilation chains (protection mechanisms,
compilers, linkers, loaders), machine-checked proofs, translation
validation, property-based testing.


Guidelines for Submitting Extended Abstracts


Extended abstracts should be submitted in PDF format and not