On Monday, June 18, 2012 4:46:32 pm Mike Meyer wrote:
> On Mon, 18 Jun 2012 13:42:27 -0500
> Nathan Whitehorn wrote:
>
> > On 06/17/12 19:43, Mike Meyer wrote:
> > > Eric McCorkle wrote:
> > >> The -m32 flag seems to be the culprit; removing it fixes the problem.
> > >> This is why I was having
On Mon, 18 Jun 2012 13:42:27 -0500
Nathan Whitehorn wrote:
> On 06/17/12 19:43, Mike Meyer wrote:
> > Eric McCorkle wrote:
> >> The -m32 flag seems to be the culprit; removing it fixes the problem.
> >> This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE
> >> were wrong.
> >>
On 06/17/12 19:43, Mike Meyer wrote:
Eric McCorkle wrote:
The -m32 flag seems to be the culprit; removing it fixes the problem.
This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE
were wrong.
In any case, this is a pretty serious error, and someone should try to
reproduce
> This is a known issue, and had been around for a long time.
> You can't reliably build 32 bit binaries (what the -m32 flag specifies)
> on a 64 bit system. The header files (and possibly other things) are wrong.
People build 32 bit binaries on 64 bit systems all the time.
It is called cross-comp
On 6/17/12 8:43 PM, Mike Meyer wrote:
Eric McCorkle wrote:
The -m32 flag seems to be the culprit; removing it fixes the problem.
This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE
were wrong.
In any case, this is a pretty serious error, and someone should try to
reproduce
Eric McCorkle wrote:
>The -m32 flag seems to be the culprit; removing it fixes the problem.
>
>This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE
>were wrong.
>
>In any case, this is a pretty serious error, and someone should try to
>reproduce it and take a look at it.
This
On 6/17/12 8:26 PM, Adrian Chadd wrote:
Hiya,
don't suppose you could file a PR for this?
Typing one up just now, after figuring out the root cause.
The short version is this: __uint64_t gets defined in
as unsigned long. This breaks when you use -m32, in
which case sizeof(unsigned long)
Hiya,
don't suppose you could file a PR for this?
Adrian
On 17 June 2012 16:10, Eric McCorkle wrote:
> On 6/17/12 6:45 PM, Eric McCorkle wrote:
>>
>> On 6/15/12 6:44 PM, Eric McCorkle wrote:
>>
>
>> int main() {
>> printf("%d\n", UINT64);
>> return 0;
>> }
>>
>
> Correction: it should be
On 6/17/12 6:45 PM, Eric McCorkle wrote:
On 6/15/12 6:44 PM, Eric McCorkle wrote:
int main() {
printf("%d\n", UINT64);
return 0;
}
Correction: it should be sizeof(UINT64)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org
On 6/15/12 6:44 PM, Eric McCorkle wrote:
However, the EFI programs I produce using the EDK system work
properly, and don't have the same issues as the ones I produce using
what's in the base system.
Okay, after a whole lot of slogging, I figured out the root of the
problems I've been seeing,
On 06/16/12 06:03, Andrey V. Elsukov wrote:
> Hi, Eric.
>
> Did you try the GNU EFI toolchain? It contains a good descriptions
> on how to build EFI application and we probably can use some
> suggestions even without importing it.
>
> http://sourceforge.net/projects/gnu-efi/
>
I did. It looks
On 16.06.2012 02:44, Eric McCorkle wrote:
> I've been working on EFI support for intel platforms. I've managed to
> build the EFI Development Kit (EDK II) and the IASL compiler for
> FreeBSD, which raises the possibility of integrating them either as
> ports, or possibly into the base system.
>
>
I've been working on EFI support for intel platforms. I've managed to
build the EFI Development Kit (EDK II) and the IASL compiler for
FreeBSD, which raises the possibility of integrating them either as
ports, or possibly into the base system.
Here is some background:
Right now, there is only on
13 matches
Mail list logo
