[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: [RFC] dietlibc port to ppc64el

[ please CC me, I'm not subscribed to the list, I only saw your reply
  by chance in the archives because I wanted to link this thread
  somewhere ]

Breno Leitao wrote:
> On 04/03/2016 06:54 PM, Christian Seiler wrote:
>> Well, you can just compile any number of standard programs (that don't
>> require external libraries) with it. Just use diet in front of gcc, e.g.
> Right. This is working fine. No problem found running the static binaries generated.

Great. :-)

>>  If you want to try a real world use cases, you could try building mksh
>> from sid with dietlibc-dev installed (you will need to update the
>> Build-Depends in debian/control and add ppc64el to the list if you use
>> an autobuilder). Then you could try running the statically linked mksh
>> variant (/bin/mksh-static in the package) and doing a few things in
>> the shell...
> Yea. Static mksh is running fine also. I tested it in normal mode and in
> the restricted mode.
>> Warning: mksh will try to link mksh-static against something else if
>> dietlibc fails, so check the build logs. (There's a summary at the
>> end.)
> Right. The build seems to happen properly, and I can see:
>  cp builddir/static/mksh debian/mksh/bin/mksh-static
>  ..
>  Dependencies:
>  | dietlibc-dev            0.34~cvs20160402.1-1~exp2+ppc64el.1
>  ....
>  Build information for static mksh
>  set -A check_categories --  shell:legacy-no int:32 smksh binsh convfds no-histfile
>  gcc (Debian 5.3.1-13) 5.3.1 20160323
>  Result: regressed (broken<firstbuilt<checked<unattended<regressed)
>  Regression test results:
>  | Total failed: 0
>  | Total passed: 506
>  Variables used:
>  | CC='klcc'

Yeah, so CC='klcc' means that this mksh was built against klibc instead
of dietlibc. CC='diet gcc' or CC='diet cc' would indicate dietlibc...
So you just verified that mksh with klibc works. :-)

Ah, I just saw: mksh seems to prefer klibc when available, which is not
all archs, and only uses dietlibc there. Now Thorsten probably has a
good reason why klibc is preferred where available, but at least for
testing purposes it might be nice to build against dietlibc. Just
remove the libklibc-dev Build-Depends and try again; if you build it on
your own system and not in e.g. pbuilder, please remove the libklibc-dev
package first before building the mksh, otherwise it will default to it

Would be interesting to see if that works.

>> Or, you could manually compile something without external deps such as
>> pwgen. (apt-get source pwgen; cd pwgen-*; ./configure CC="diet gcc";
>> make; ./pwgen to test it.)
> Package pwgen is also working fine. No error on compiling or testing it.

Great! :-)

I just removed a bit of useless code from the startup code of
dietlibc, which was left over from my experiments. In a qemu
environment this seems to work well, but could you test that on real
hardware? I've pushed a patch that removes the lines I deem probably
useless to git (same branch, [1]), it would be great if you could
test this stuff again.

Also, should I add the global entry trampoline and then .localentry
to all assembly functions that might be called from C code,
especially all syscalls? (syscalls jump to __unified_syscall, which
could call __errno_location, which will then try to access a global
variable, which uses the TOC register r2 internally.) And while
technically r2 should remain constant throughout execution of a
statically linked program, the spec says that if you don't have a
local entry point (st_other == 0), you can't rely on r2 - so if I'm
reading what my code currently does correctly is that it kind of
relies on undefined behavior here? Or is there some other guarantee
that the current code will work in all cases?

Anyway, thanks a lot for your responses so far.


[1] https://anonscm.debian.org/cgit/collab-maint/dietlibc.git/commit/?h=ports/ppc64el

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: