* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
*
It won't, but if you use the attached patch it seems to. Let me know if
it looks good and I'll tack it onto my queue. Also, is there a solid
reason the create functions can't end up in a namespace other than the
global one? I'm ending up with some pretty horrible names trying to make
sure
What about making Enums recognize cxx_namespace too? That would be
pretty handy although I'm not sure how feasible. There seems to be a
global list of them that would probably get confused if there was more
than one with the same name, even if they were in separate modules.
Gabe
Gabe Black
Is there some way we can make m5 link incrementally, or in other words
link subsystems together independently and then as units with each
other? The final linking step seems to take a long time with ld at 100%
cpu usage. That makes sense when you consider it's linking a screen and
a half
I quickly scanned the SCons documentation and couldn't find anything
built in, but clearly the kernel does it so it can be done.
Ali
On Jun 9, 2008, at 5:48 AM, Gabe Black wrote:
Is there some way we can make m5 link incrementally, or in other
words
link subsystems together
Few comments.
1) I like this idea.
2) Linux explicitly exports symbols outside of an object. This seems
like it would be a pain.
3) Anonymous namespaces aren't obscure. Maybe there's a way to remove
these with strip.
4) It shouldn't be hard to get SCons to support this sort of thing.
Nate
On
It won't, but if you use the attached patch it seems to. Let me know if
it looks good and I'll tack it onto my queue.
Patch looks good.
Also, is there a solid
reason the create functions can't end up in a namespace other than the
global one? I'm ending up with some pretty horrible names
So this would be the PCI bus support in the north bridge for instance?
Should I just arbitrarily pick a chipset and implement that, or is there
something more generic?
Gabe
nathan binkert wrote:
So as it says, it's checking bus 0 device 0 for a host bridge. Do we
have a way to set that up? I
I've done some reading online and it doesn't appear that incremental
linking will cut down on the link time much at all. Doing it in
smaller chunks doesn't help if all the symbols end up being exported
at the end. The two ways to speed it up are to (a) not include any
debugging information
That makes sense to me. I can do that at some point or if you'd rather
that'd be fine too.
Gabe
nathan binkert wrote:
It won't, but if you use the attached patch it seems to. Let me know if
it looks good and I'll tack it onto my queue.
Patch looks good.
Actually, does it make sense to get
Whoever gets to it. If you don't want to do it instead of the simple
patch you wrote, we can put it on the todo list. In general, that
code is getting pretty messy and needs some TLC.
On Mon, Jun 9, 2008 at 11:21 AM, Gabe Black [EMAIL PROTECTED] wrote:
That makes sense to me. I can do that at
Yeah, that makes sense. We don't really have subsystems with local
symbols. That said, is it faster to incremental link strip and then
finish the link? I'm just curious if there are any symbols that we
can automatically strip.
Then again, I build debug most of the time and you wouldn't want to
So this would be the PCI bus support in the north bridge for instance?
Should I just arbitrarily pick a chipset and implement that, or is there
something more generic?
I think that there's really only one interface for this that really
matters. On alpha, there were lots of north bridge
One thing to try maybe is Intel CC. Perhaps their linker is faster? or
do they use ld? You're probably running into a I/O limitation on your
laptop not a CPU problem.
Ali
On Jun 9, 2008, at 2:02 PM, nathan binkert wrote:
Yeah, that makes sense. We don't really have subsystems with local
14 matches
Mail list logo
