[llvm-dev] Need help with code generation

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 21 17:15:26 PDT 2016


----- Original Message -----
> From: "Rafael EspĂ­ndola via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "James Molloy" <james at jamesmolloy.co.uk>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Bruce Hoult" <bruce at hoult.org>
> Sent: Monday, March 21, 2016 4:23:10 PM
> Subject: Re: [llvm-dev] Need help with code generation
> 
> On 21 March 2016 at 17:20, James Molloy via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Rafael,
> >
> > How can a high quality product crash by design? I understand the
> > lack of
> > structured error handling, and I understand asserting (which in
> > release mode
> > would be silent) on internal errors. But on an input? How can an
> > application
> > be taken seriously when crashes are design features?
> >
> > And I certainly didn't see consensus or in fact the suggestion of
> > this in
> > the other thread, unless I glazed over an important part.
> >
> 
> It can crash because .o files are not user input. They are generated.
> To get one you need a broken assembler or a broken hardware.

Linker inputs come from .a and .so files which are shipped and long-lived (i.e. subject to file-system/transfer corruption), and might contain data crafted by a malicious party. So, are we just talking about segfaults under otherwise-controlled circumstances (i.e. I could install some signal handlers to catch all such cases), or are we talking about arbitrary buffer overruns? The latter seems like a potential security problem.

Thanks again,
Hal

> Sorry if lld is not the linker you want, but that is the one we are
> writing.
> 
> As for how it will be taken seriously, well, we seem to be on good
> track to be able to link freebsd and to do so faster than gold.
> 
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory


More information about the llvm-dev mailing list