llvm dev - May 2016 - [cfe-dev] How to debug if LTO generate wrong code?

Hi Joerg,
My firmware case is I need load my firmware to run in high address which is
hardware required. It is not that my firmware really need large static data and
text code. My firmware modules are	 shared library (like a DLL) built with
"-fpic", and firmware loader will load them to high address (larger
than 2GB). I think this need is quite common to system software, like firmware,
driver and kernel mode code.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Joerg
> Sonnenberger via llvm-dev
> Sent: Monday, May 30, 2016 8:27 AM
> To: cfe-dev at lists.llvm.org; llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] [cfe-dev] How to debug if LTO generate wrong code?
> 
> On Mon, May 30, 2016 at 12:10:09AM +0000, Shi, Steven via cfe-dev wrote:
> > I'm a bit surprised if both OS X ld64 and gold plugin do not
support
> > large code model in LTO. Since modern system widely use the 64bit, the
> > code need to run in high address (larger than 2 GB) is a reasonable
> requirement.
> 
> Actually, given that PIC is (almost) free in terms of codegen, there is
> rarely a need for the large model on AMD64. Programs with more than 2GB
> of static data are moderately rare and programs with more than 2GB of
> text even more so.
> 
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

On Mon, May 30, 2016 at 02:12:09AM +0000, Shi, Steven via llvm-dev
wrote:
> Hi Joerg,
> My firmware case is I need load my firmware to run in high address
> which is hardware required. It is not that my firmware really need
> large static data and text code. My firmware modules are shared library
> (like a DLL) built with "-fpic", and firmware loader will load
them to
> high address (larger than 2GB). I think this need is quite common to
> system software, like firmware, driver and kernel mode code.
It sounds more like there a confusion about what symbols are internal
and what not. The normal code model on AMD64 requires code and data to
fit into 2GB, but non-local symbols are accessed indirectly. That
doesn't happen in your case. For functions, that's normally partially
the job of the linker (via stubs), but for data the compiler has to be
aware of it. The load address is irrelevant for PIC.

Joerg

Yes, the "normal" code model you mentioned is the small code model,
which use RIP-relative addressing, but my firmware need large code model which
can reside anywhere in the full 64-bit address space. So, I need LLVM LTO
support large code model.

Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Joerg
> Sonnenberger via llvm-dev
> Sent: Monday, May 30, 2016 6:18 PM
> To: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] [cfe-dev] How to debug if LTO generate wrong code?
> 
> On Mon, May 30, 2016 at 02:12:09AM +0000, Shi, Steven via llvm-dev wrote:
> > Hi Joerg,
> > My firmware case is I need load my firmware to run in high address
> > which is hardware required. It is not that my firmware really need
> > large static data and text code. My firmware modules are shared
library
> > (like a DLL) built with "-fpic", and firmware loader will
load them to
> > high address (larger than 2GB). I think this need is quite common to
> > system software, like firmware, driver and kernel mode code.
> 
> It sounds more like there a confusion about what symbols are internal
> and what not. The normal code model on AMD64 requires code and data to
> fit into 2GB, but non-local symbols are accessed indirectly. That
> doesn't happen in your case. For functions, that's normally
partially
> the job of the linker (via stubs), but for data the compiler has to be
> aware of it. The load address is irrelevant for PIC.
> 
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev