Hi,
On Tue, May 24, 2011 at 4:09 PM, Arnaud Lacombe wrote:
> Many Makefile (espectially under sys/boot/) overwrite the value of CFLAGS.
> This is an issue if you want to generate code for a specific CPU as before the
> Makefile is interpreted, CFLAGS might already have been set with CPU specific
Hi,
On Wed, May 25, 2011 at 4:10 PM, Arnaud Lacombe wrote:
> I'm now trying to track down the original instruction triggering the
> SIGILL, but it is in a library and that section of the memory does not
> seem to be included in the core. Moreover I do not think I have any
> way on a broken system
Hi,
On Wed, May 25, 2011 at 3:44 PM, John Baldwin wrote:
> On Wednesday, May 25, 2011 1:03:10 pm Arnaud Lacombe wrote:
>> Hi,
>>
>> On Wed, May 25, 2011 at 12:28 PM, John Baldwin wrote:
>> > On Wednesday, May 25, 2011 11:34:29 am Arnaud Lacombe wrote:
>> >> Hi,
>> >>
>> >> On Wed, May 25, 2011 a
On Wednesday, May 25, 2011 1:03:10 pm Arnaud Lacombe wrote:
> Hi,
>
> On Wed, May 25, 2011 at 12:28 PM, John Baldwin wrote:
> > On Wednesday, May 25, 2011 11:34:29 am Arnaud Lacombe wrote:
> >> Hi,
> >>
> >> On Wed, May 25, 2011 at 9:43 AM, John Baldwin wrote:
> >> >> The original trouble I met,
On Wed, May 25, 2011 at 09:43:15AM -0400, John Baldwin wrote:
> It may be that your jail is not a pure 32-bit jail (some things like a 32-bit
> ps won't really work in with a 64-bit host for example). Also, until
Err, is it broken (again) ? I committed the 32bit compat shims for kinfo_proc
long
Hi,
On Wed, May 25, 2011 at 12:28 PM, John Baldwin wrote:
> On Wednesday, May 25, 2011 11:34:29 am Arnaud Lacombe wrote:
>> Hi,
>>
>> On Wed, May 25, 2011 at 9:43 AM, John Baldwin wrote:
>> >> The original trouble I met, is that building for an i586 target in a
>> >> 32bits jail, on top of an am
on 25/05/2011 19:28 John Baldwin said the following:
> On Wednesday, May 25, 2011 11:34:29 am Arnaud Lacombe wrote:
>> The more broad issue with the setup is that gcc within that
>> environment, without being told -march=i586, produces i686
>> instructions which are incompatible with the target CPU
On Wednesday, May 25, 2011 11:34:29 am Arnaud Lacombe wrote:
> Hi,
>
> On Wed, May 25, 2011 at 9:43 AM, John Baldwin wrote:
> >> The original trouble I met, is that building for an i586 target in a
> >> 32bits jail, on top of an amd64 system[0] (I do not have control over
> >> that setup) produce
Hi,
On Wed, May 25, 2011 at 9:43 AM, John Baldwin wrote:
> On Tuesday, May 24, 2011 5:30:37 pm Arnaud Lacombe wrote:
>> Hi,
>>
>> On Tue, May 24, 2011 at 4:41 PM, Dimitry Andric wrote:
>> > On 2011-05-24 22:09, Arnaud Lacombe wrote:
>> >>
>> >> Many Makefile (espectially under sys/boot/) overwri
Hi,
On Wed, May 25, 2011 at 9:43 AM, John Baldwin wrote:
>> The original trouble I met, is that building for an i586 target in a
>> 32bits jail, on top of an amd64 system[0] (I do not have control over
>> that setup) produces incorrect binaries. The current fix I've got is
>> to define MACHINE_AR
On Tuesday, May 24, 2011 5:30:37 pm Arnaud Lacombe wrote:
> Hi,
>
> On Tue, May 24, 2011 at 4:41 PM, Dimitry Andric wrote:
> > On 2011-05-24 22:09, Arnaud Lacombe wrote:
> >>
> >> Many Makefile (espectially under sys/boot/) overwrite the value of
CFLAGS.
> >> This is an issue if you want to gene
on 25/05/2011 15:25 Ruslan Ermilov said the following:
> On Tue, May 24, 2011 at 11:08:52PM -0400, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Tue, May 24, 2011 at 10:54 PM, Arnaud Lacombe wrote:
>>> ps: for static library and loader, I derived the total size as the sum
>>> of the size of the text/data/
On Tue, May 24, 2011 at 11:08:52PM -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Tue, May 24, 2011 at 10:54 PM, Arnaud Lacombe wrote:
> > ps: for static library and loader, I derived the total size as the sum
> > of the size of the text/data/bss section of the member object using :
> >
> > size *.o |
Hi,
On Tue, May 24, 2011 at 10:54 PM, Arnaud Lacombe wrote:
> ps: for static library and loader, I derived the total size as the sum
> of the size of the text/data/bss section of the member object using :
>
> size *.o | awk 'BEGIN {text=0; data=0; bss=0;}; {text+=$1; data+=$2;
> bss+=$3}; END {pr
Hi,
On Tue, May 24, 2011 at 4:41 PM, Dimitry Andric wrote:
> Besides, for space-constrained things like boot2, you
> might not even be able to compile it when using non-standard settings,
> since the code might grow too large.
>
About the size, let's get some number
lib/libstand (library): (with
Hi,
On Tue, May 24, 2011 at 4:41 PM, Dimitry Andric wrote:
> On 2011-05-24 22:09, Arnaud Lacombe wrote:
>>
>> Many Makefile (espectially under sys/boot/) overwrite the value of CFLAGS.
>> This is an issue if you want to generate code for a specific CPU as before
>> the
>> Makefile is interpreted,
On 05/24/2011 13:41, Dimitry Andric wrote:
So that is why these Makefiles purposefully overwrite CFLAGS, it is not
by accident.
In those cases adding comments to the Makefile is probably appropriate,
if they are not present already. Something to the effect of, "Purposely
overwriting CFLAGS be
On 2011-05-24 22:09, Arnaud Lacombe wrote:
Many Makefile (espectially under sys/boot/) overwrite the value of CFLAGS.
This is an issue if you want to generate code for a specific CPU as before the
Makefile is interpreted, CFLAGS might already have been set with CPU specific
settings by, which is
Many Makefile (espectially under sys/boot/) overwrite the value of CFLAGS.
This is an issue if you want to generate code for a specific CPU as before the
Makefile is interpreted, CFLAGS might already have been set with CPU specific
settings by , which is source from sys.mk.
Signed-off-by: Arnaud L
19 matches
Mail list logo
