Re: native gdb for Android
Barry Song <21cn...@gmail.com> wrote: > So my questions are: > > 1. Should I compile the native gdb using android toolchain and android > bionic/libthread libraries? > 2. Why can’t the current gdb capture multithreads for android > processes? This question is actually about the theory for gdb to know > multi-threads. In my opinion, both gnu and android use clone() to fork > threads and threads in one process have same tgid in kernel and all > threads return same getpid() value. Why not gdb just travel process > lists to find multi-threads? I'm not sure what exactly is going on on Android with bionic. However, GDB currently does require support from the thread library in order to debug multi-threaded applications. This is needed e.g. to properly handle thread-local storage variables. GDB will also use this support to detect threads of a running process it is attaching to. (It is true that GDB *could* e.g. look at /proc to find threads, instead of inspecting thread library data structures. However, since the link to those data structures is required anyway, e.g. for TLS, this has not been implemented so far ...) When using glibc's libpthread, the support routines gdb uses to inspect target thread library datastructures are provided in libthread_db.so.1 (which comes with glibc, and is linked into gdb). I do not know the details on whether/how bionic provides a corresponding service. However, from looking at the gdbserver sources provided with Android, it seems there are some differences; in particular, there's this patch: +/* Android doesn't have libthread_db.so.1, just libthread_db.so. */ +#ifdef __ANDROID__ +#define LIBTHREAD_DB_SO "libthread_db.so" +#endif + If libthread_db is named differently, this would explain why GDB is unable to find and use it. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: native gdb for Android
Barry Song <21cn...@gmail.com> wrote. > 2012/2/3 Ulrich Weigand : > > However, from looking at the gdbserver sources provided with Android, > > it seems there are some differences; in particular, there's this patch: > > > > +/* Android doesn't have libthread_db.so.1, just libthread_db.so. */ > > +#ifdef __ANDROID__ > > +#define LIBTHREAD_DB_SO "libthread_db.so" > > +#endif > > + > > > > If libthread_db is named differently, this would explain why GDB is > > unable to find and use it. > > there are two ways to handle this issue: > 1. ln -s /system/lib/libthread_db.so /system/lib/libthread_db.so.1 That would seem a good thing in any case. (Is there any reason for Android to use nonstandard shared library naming conventions?) > this "fixed" Assertion `_rtld_global_ro._dl_pagesize != 0' , but it > still can't find multi-threads for android processes: > (gdb) info threads > Id Target Id Frame > * 1process 645 "system_server" __ioctl () > at bionic/libc/arch-arm/syscalls/__ioctl.S:15 > > (gdb) info threads > Id Target Id Frame > * 1process 938 "mediaserver" __ioctl () > at bionic/libc/arch-arm/syscalls/__ioctl.S:15 I had a quick look at the AOSP sources, and found that there actually is an implementation of libthread_db that is supposed to work with bionic. Well, there seem to be multiple versions: ./bionic/libthread_db ./ndk/sources/android/libthread_db/gdb-6.6 ./ndk/sources/android/libthread_db/gdb-7.1.x I'm not sure why there needs to be a different version for each GDB(server) release ... Maybe there's something in there that also needs changing when it's being used by GDB directly instead of by gdbserver. I'll probably not be able to help you very much here; I'd suggest you 1) make sure your GDB actually uses the correct version of libthread_db (in particular, not one from glibc, but this one that handles bionic) and 2) if it still doesn't work, you'll have to debug what's going wrong. Note that from a quick look at the above libthread_db sources, those actually do not look into bionic data structures at all, but rather just traverse /proc to get a thread list. While this is somewhat odd (if you want to do that, you could just do it in gdb/server itself -- the only reason why libthread_db is a separate project is its close integration with the thread library), it ought to make it easier to understand what's going on / wrong. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: gcc: Thumb interworking and weakly linked functions
"V, Aneesh" wrote:
> I agree that not marking the assembly functions ' %function' is a problem
> in the code, so it's not a critical bug. But I would've been happier if
> the linker refused to link it rather than branching with the wrong
> instruction. Isn't that a problem?
Well, if the target symbol of a branch is not marked as %function,
the linker has no way of knowing whether that target is ARM or Thumb,
so it cannot specifically error out if (and only if) the instruction
is wrong.
The linker *could* in theory give an error *unconditionally* whenever
it detects a branch to a non-%function symbol. The reason this is not
done is probably for backwards compatibility with old hand-written code,
say from an ARM-only era: branches to non-function symbols used to be
allowed, and in fact work fine if all code is ARM-only. Adding an error
would break such old code.
> Problem No:2
> *
> Linaro GCC 2012.01 is giving a new problem w.r.to Thumb build
> that is not existing in Sourcery G++ Lite 2010q1-202. However, I
> couldn't reproduce this problem with a small program like above. So,
> let me give you reference to the original u-boot code that shows the
> problem and steps to reproduce it.
[snip]
> Please note that the .rodata symbols have odd addresses. These arrays
> actually need to be aligned at least to half-word boundary. In fact, in
> the image I verified that they are put at even addresses. So, the
> symbols have been kept as real address +1.
This seems strange. How did you verify "that they are put at even
addresses"?
I can reproduce the odd addresses of .rodata symbols. However, this
occurs simply because the linker put *no* alignment requirement whatsoever
on those sections:
Section Headers:
[Nr] Name TypeAddr OffSize ES Flg Lk
Inf Al
[snip]
[11] .rodata.wkup_padc PROGBITS 000100 04 00 A 0
0 1
[12] .rodata.wkup_padc PROGBITS 000104 48 00 A 0
0 1
[13] .rodata.wkup_padc PROGBITS 00014c 0c 00 A 0
0 1
[14] .rodata.wkup_padc PROGBITS 000158 04 00 A 0
0 1
Note the "Al" column values of 1. In the final executable, those sections
happen to end up immediately following a .rodata.str string section with
odd
lenght, and since they don't have any alignment requirement, they start out
at an odd address.
The reason for the lack of alignment requirement is actually in the source:
const struct pad_conf_entry core_padconf_array_essential[] = {
where
struct pad_conf_entry {
u16 offset;
u16 val;
} __attribute__ ((packed));
The "packed" attribute specifies that all struct elements ought to be
considered to have alignment requirement 1 instead of their default
alignment. Thus the whole struct ends up having alignment requirement 1;
and since the section contains only a single variable of such struct
type, this is then also the alignment requirement of the section.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: gcc: Thumb interworking and weakly linked functions
Andrew Stubbs wrote on 21.02.2012 11:56:07: > I'm not sure, but I believe that the compiler requires (prefers) any > structs that you want included inside packed structs to be themselves > packed, so you can end up with some structs with apparently unnecessary > attributes on them. I don't see why the compiler would care. Its just that if an inner struct already has padding somewhere, this padding doesn't go away (the struct layout is not recomputed) just because it is embedded in a larger struct which is marked packed. [Marking the outer struct packed will still affect the overall alignment requirement of the inner struct; it just won't affect it inner layout.] > It might also have an effect when you place the struct inside an > unpacked struct? Yes, of course: if the struct is packed, then the struct as a whole has an alignment requirement of 1, which may affect the placement of the struct as an element within an outside (unpacked) struct. > Without context I've no idea whether that's what's going on here. Of > course, a no-op "packed" attribute ought to be harmless... It is not really "no-op": it reduces the alignment requirement of the struct from 2 (in this case) to 1, which is actually exactly what's causing the problems in the original test case. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: gcc: Thumb interworking and weakly linked functions
Aneesh V wrote on 23.02.2012 11:27:40:
> > The "packed" attribute specifies that all struct elements ought to be
> > considered to have alignment requirement 1 instead of their default
> > alignment. Thus the whole struct ends up having alignment requirement
1;
> > and since the section contains only a single variable of such struct
> > type, this is then also the alignment requirement of the section.
> >
>
> Hmm.. Thanks. Removing packed seems to help. The following also helped.
>
> @@ -34,7 +34,7 @@ struct pad_conf_entry {
>
> u16 val;
>
> -} __attribute__ ((packed));
> +} __attribute__ ((packed)) __attribute__ ((aligned(2)));
>
> BTW, just for my understanding:
> The effect of adding __attribute__ ((packed)) to a structure is
> equivalent to adding it for each field in the structure, right?
Right.
> And because the first field doesn't have any alignment requirement,
> the struct also doesn't have any alignment requirement right?
Sort of. The alignment requirement of the struct is the maximum
(actually, the least common multiple, but since we're talking only
powers of two, that amounts to the same) of the alignment requirements
of all members. However, attribute packed for a struct applies to
each element separately, and thus each element has alignment
requirement 1, which is then also the maximum.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: GCC Explorer.. on ARM?
Christian Robottom Reis wrote: > GCC Explorer.. on ARM? > > http://xania.org/201205/gcc-explorer > > Could we get Matt to provide a cross-compiler environment too? He's > already using gcc-linaro anyway.. ;-) It seems his version on gcc.godbolt.org already supports a ARM cross-compiler; the list box on the right hand side allows to select "arm-linux-gnueabi-g++-4.5" in addition to the native compiler versions. This is probably just the standard ARM cross-compiler package provided on Ubuntu (which these days uses the Linaro compiler sources, of coutse) ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Please help us setup patches.linaro.org
Guilherme Salgado wrote: > And there's a form at the bottom which allows them to be moved to the > appropriate project. If we're missing a project just let me know and > I'll create it. It looks like there's no project for valgrind; I have two patches accepted there ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Please help us setup patches.linaro.org
Guilherme Salgado wrote: > Is there a mailing list to which valgrind patches are sent? If we have > one whenever you send a patch to that list with patches@l.o CCed we'll > be able to detect it's a valgrind patch and move it to the correct > project. No, there isn't. Valgrind patch contributions work by attaching the patch to a bugzilla record; Julian Seward then takes the patch from there and commits it to the repository. (Note that there isn't even a separate bugzilla for valgrind; they use the KDE bugzilla at bugs.kde.org while setting the "product" field to "valgrind".) Since I don't expect there to be a significant number of further Linaro contributions to valgrind, it's probably not worthwhile to spend effort trying to automate tracking those ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Static Library startup
Tom Gall wrote: > For shared libs one can define and use something like: > > void __attribute__ ((constructor)) my_init(void); > void __attribute__ ((destructor)) my_fini(void); > > Which of course allows your lib to run code just after the library is > loaded and just before the library is going to be unloaded. > Unfortunately this doesn't work when people link in the .a from your > lib. Irrespectively of whether it is a good idea to design your library such as to require constructor/destructor routines (:-)) these attributes should work just fine for code that is statically linked. In those cases, the constructor is called early during process startup, and the destructor is called during process exit. So I'm not quite sure why you say this "doesn't work". Absent further details, I can speculate that you might have been running into problems relating to either: - missing object references When linking against a shared library, that whole library gets loaded as a unit, and will always have all its constructors. When linking against a static library, only such object files that are actually (directly or indirectly) referenced by the caller will get pulled into the final executable. If your constructor/destructor routines happen to reside in objects that are not otherwise references, they will simply not be present in the executable and thus not called either. This type of problems can be fixed by keeping constructors/destructors in object files next to routines that rely on them. For example, if you need a constructor to set up a data structure before it can be used, keep the constructor in the same file that provides the main accessor routines to that data structure, such that every user of the data structure must always pull in that object -- and hence the constructor. - initialization order issues The constructors will be called during early startup, which might not be the proper place for whatever they're trying to do (e.g. they might call some other library which itself wasn't initialized yet ...). This is really the same type of problem you also have with shared libraries that are loaded at startup (i.e. not via dlopen), but the details of the constructor call sequence might change in the static case. Does either of those explain the problems you were seeing? Otherwise, if you have more details of what exactly you tried and what went wrong, I'd be happy to have a look ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: "struct user" conflicts on arm
Wookey wrote: > We can > 1) Change every app in the world that defines a 'struct user' > 2) Stop these headers getting brought in when not actually needed > (it's a relatively recent change that brings it in) > 3) Change the name in glibc/GDB to something less likely to clash Some background from a GDB perspective: the files and define the layout of the various register sets the kernel provides to user space debuggers via ptrace and/or core file register note sections. In the past, it was considered a good idea for this information to be provided by kernel headers via inclusion into glibc to be used by GDB sources. However, this turned out to not be really feasible with modern GDB: since this information is needed to access core files, and with a cross-debugger we need to access core files produced on some other architecture than the host, we cannot actually rely on system headers (which only provide information about the host architecture). Fortunately, the layout is part of the unchanging kernel ABI, so there is no real need for GDB to rely on any header files in the first place. Therefore, GDB is currently in the process to switching to simply hard-coding register set layouts for various architectures. Once this process is complete, and will no longer be needed to build GDB. (The process is mostly complete for ; it will still take a while for .) However, from a system perspective, it is probably still not a good idea to just remove (or incompatibly change) those headers: you want to keep the capability to compile older GDB sources (and possibly other debuggers). Now, glibc also provides a file that defines layouts of register sets for use with signal handlers as well as the makecontext/setcontext/getcontext family of routines. Usually, those layouts tend to be in fact identical to the layouts described in / . Apparently, whoever implemented the ARM version of was trying to avoid some seemingly unnecessary code duplication by making *include* and using the information from there directly. This is not done on other platforms, for precisely the reason that the and headers do pollute the name space ... So I think the right thing to do in the short term would be to stop including , and instead add the register set information there directly, even if that means some duplication of code. (Again, since this is never-changing ABI, duplication isn't actually all that bad. Also, all the other platforms do it that way too, so why should ARM be different ...) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro gcc ICE bug
Khem Raj wrote: > The bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46883 files > against GCC trunk also happens with linaro gcc 4.5 > My guess is that there is a backported patch from trunk into linaro > 4.5 tree thats causing this ICE > > This ICE does not happen on upstream gcc-4.5 branch Thanks for the bug report! > I havent figured out the commit yet. It looks like the regression was introduced by Bernd Schmidt's patch to improve zero-/sign-extensions (PR 42172), which we did indeed backport to Linaro GCC 4.5. (I've updated the PR 46883 bugzilla with more details.) > Should you need a bug in linaro > bug tracker I will be happy to file one Yes, please do so; this makes it easier to track the problem on the Linaro side. Thanks! Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Kernel fixes for HW watchpoint support
Hi Nicolas, hi John, during tests of hardware watchpoint support for GDB I run into a couple of Linux kernel issues: - On (some versions of?) Versatile Express SMP Cortex-A9 SMP boards, a CPU errata (#720789) causes TLB flushes to sometime fail, which can lead to random problems when running GDB in SMP mode (and probably elsewhere). There is a kernel work-around for this problem activated by CONFIG_ARM_ERRATA_720789, but this is unfortuantely not active on the Linaro kernels. (On OMAP4, this happens automatically due to an entry in mach-omap2/Kconfig. There is no such entry in mach-vexpress/Kconfig currently.) - On machines that do not support watchpoints (e.g. IGEP with current kernels), this fact is not reported properly to user space. Will Deacon posted a patch to fix this: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/041492.html Can we get fixes for these issues included in the Linaro kernel (git tree and/or packages ... not sure where the best place would be)? Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: Kernel fixes for HW watchpoint support
"Will Deacon" wrote on 02/21/2011 06:56:13 PM: > > > - On (some versions of?) Versatile Express SMP Cortex-A9 SMP boards, a CPU > > > errata (#720789) causes TLB flushes to sometime fail, which can lead to > > > random problems when running GDB in SMP mode (and probably elsewhere). > > > There is a kernel work-around for this problem activated by > > > CONFIG_ARM_ERRATA_720789, but this is unfortuantely not active on the > > > Linaro kernels. (On OMAP4, this happens automatically due to an entry in > > > mach-omap2/Kconfig. There is no such entry in mach-vexpress/Kconfig > > > currently.) > > > > Could you send a patch to Russell for that? > > I have a patch that enables some other workarounds that we probably > want enabled for the VE as well. Great, thanks! > I can CC you (Ulrich) on that if you'd prefer? Sure, that's fine with me ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Kernel fixes for HW watchpoint support
Nicolas Pitre wrote on 02/21/2011 06:48:10 PM: > This is included in the Linaro kernel repository already: > > http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6. > 37.git;a=commit;h=40ef21c84e > > Next packaging of the kernel will pick it up. Ah, I missed that, sorry. Thanks! Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: gcc: Thumb interworking and weakly linked functions
Aneesh V wrote:
> I was trying to build u-boot in Thumb2 for OMAP4. Everything was fine
> until I added some patches recently. One of these patches introduced an
> API (let's say foo()) that has a weakly linked alias(let's say
> __foo()) and a strongly linked implementation(the real foo()) in an
> assembly file.
>
> Although I give -mthumb and -mthumb-interwork for all the files,
> apparently GCC generates ARM code for assembly files. In the final
> image foobar() calls foo() using a BL. Since foobar() is in Thumb and
> foo() in ARM, it ends up crashing. Looks like foobar() assumed foo()
> to be Thumb because __foo() is Thumb.
I'm unable to reproduce this. Do you have a complete test case?
I've tried with the following small example:
foo1.c:
extern void foo (void) __attribute__ ((weak, alias ("__foo")));
void __foo (void)
{
}
int main (void)
{
foo ();
}
foo2.S:
.text
.align 2
.global foo
.type foo, %function
foo:
push{r7}
add r7, sp, #0
mov sp, r7
pop {r7}
bx lr
.size foo, .-foo
When building just "gcc foo1.c", I get:
835c <__foo>:
835c: b480push{r7}
835e: af00add r7, sp, #0
8360: 46bdmov sp, r7
8362: bc80pop {r7}
8364: 4770bx lr
8366: bf00nop
8368 :
8368: b580push{r7, lr}
836a: af00add r7, sp, #0
836c: f7ff fff6 bl 835c <__foo>
8370: 4618mov r0, r3
8372: bd80pop {r7, pc}
When building both files "gcc foo1.c foo2.S", I get instead:
8368 :
8368: b580push{r7, lr}
836a: af00add r7, sp, #0
836c: f000 e802 blx 8374
8370: 4618mov r0, r3
8372: bd80pop {r7, pc}
8374 :
8374: e92d0080push{r7}
8378: e28d7000add r7, sp, #0
837c: e1a0d007mov sp, r7
8380: e8bd0080pop {r7}
8384: e12fff1ebx lr
So it seems to me the linker is handling this correctly ...
(This is on Ubuntu Natty using system gcc and binutils.)
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: gcc: Thumb interworking and weakly linked functions
Aneesh V wrote on 03/16/2011 10:32:50 AM:
> Can you try this sequence:
>
> arm-linux-gnueabi-gcc -march=armv7-a -mthumb -mthumb-interwork -o foo1.o
> foo1.c -c
> arm-linux-gnueabi-gcc -march=armv7-a -mthumb -mthumb-interwork -o foo2.o
> foo2.S -c
> arm-linux-gnueabi-ld -r foo1.o foo2.o
> arm-linux-gnueabi-objdump -S a.out
>
> With this sequence I get the following output:
> 000c :
> c: b580 push {r7, lr}
> e: af00 add r7, sp, #0
>10: f7ff fffebl 18
>14: 4618 mov r0, r3
>16: bd80 pop {r7, pc}
>
> 0018 :
>18: e92d0080push {r7}
>1c: e28d7000add r7, sp, #0
>20: e1a0d007mov sp, r7
>24: e8bd0080pop {r7}
>28: e12fff1ebx lr
Well, sure, but the result of "ld -r" is not a final executable, but just
another relocatable object file. In particular, it will still carry
relocation records. In fact, if you add --reloc to the objdump line,
you should see:
000c :
c: b580push{r7, lr}
e: af00add r7, sp, #0
10: f7ff fffe bl 18
10: R_ARM_THM_CALL foo
14: 4618mov r0, r3
16: bd80pop {r7, pc}
The R_ARM_THM_CALL marks the branch instruction as still to be processed
by the final link step. And once you actually *perform* the final link,
e.g. via "gcc -o final a.out", the branch gets indeed converted to a blx
by the linker for me:
836c :
836c: b580push{r7, lr}
836e: af00add r7, sp, #0
8370: f000 e802 blx 8378
8374: 4618mov r0, r3
8376: bd80pop {r7, pc}
8378 :
8378: e92d0080push{r7}
837c: e28d7000add r7, sp, #0
8380: e1a0d007mov sp, r7
8384: e8bd0080pop {r7}
8388: e12fff1e bx lr
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: gcc: Thumb interworking and weakly linked functions
Aneesh V wrote:
> On Wednesday 16 March 2011 07:14 PM, Ulrich Weigand wrote:
> > The R_ARM_THM_CALL marks the branch instruction as still to be
processed
> > by the final link step. And once you actually *perform* the final
link,
> > e.g. via "gcc -o final a.out", the branch gets indeed converted to a
blx
> > by the linker for me:
>
> This doesn't seem to be happening with U-boot. In U-boot, the situation
> is like this:
>
> U-Boot builds multiple individual libraries and finally link them
> together. The call to the API and the weakly linked implementation is
> in one library(libarmv7.o), while the real implementation in assembly
> is in another library(libomap4.o). Here are the relevant contents of
> these libraries and the final image "u-boot" for your reference:
>
> liarmv7.o:
> 01b6 :
> }
>
> void arm_init_before_mmu(void)
> {
> 1b6: b508 push {r3, lr}
>v7_outer_cache_enable();
> 1b8: f7ff fffebl 1f0 <__v7_outer_cache_enable>
> 1b8: R_ARM_THM_CALL v7_outer_cache_enable
>
> libomap4.o:
> 111c :
>
> .globl v7_outer_cache_enable
> v7_outer_cache_enable:
>MOV r0, #1
> 111c: e3a1mov r0, #1
>B set_pl310_ctrl_reg
> 1120: eaf9b 110c
>
> u-boot:
> void arm_init_before_mmu(void)
> {
> 80100636: b508 push {r3, lr}
>v7_outer_cache_enable();
> 80100638: f001 f998bl 8010196c <_end+0xfffaf2a4>
>
>
> Here are the intermediate link commands used for the libraries:
> arm-linux-gnueabi-ld -r -o libarmv7.o cpu.o cache_v7.o syslib.o
> arm-linux-gnueabi-ld -r -o libomap4.o board.o mem.o sys_info.o ...
Well, those aren't really "libraries" strictly speaking, since they
are build with "ld -r", so they're actually just regular object files.
But that doesn't really matter one way or the other ...
> Here is the final link command(shortened and line-wrapped in the
> interest of readability - attaching the full build log):
> UNDEF_SYM=`arm-linux-gnueabi-objdump -x arch/arm/cpu/armv7/libarmv7.o
> arch/arm/cpu/armv7/omap4/libomap4.o arch/arm/lib/libarm.o | sed -n -e
> 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd /home/a0393566local
> /u-boot-denx-bak && arm-linux-gnueabi-ld -pie -Bstatic -T u-boot.lds
> -Ttext 0x8010 $UNDEF_SYM arch/arm/cpu/armv7/start.o --start-group
> arch/arm/cpu/armv7/libarmv7.o arch/arm/cpu/armv7/omap4/libomap4.o
> arch/arm/lib/libarm.o --end-group /home/a0393566local/u-boot-denx-bak
> /arch/arm/lib/eabi_compat.o -L /usr/lib/gcc/arm-linux-gnueabi/4.5.2
> -lgcc -Map u-boot.map -o u-boot
>
> I don't know what the UNDEF_SYM is about. Do you think that could be
> creating a problem?
I can't see how ... this just adds a bunch of undefined symbols via -u
options, which presumably causes some objects to be pulled into the
final link that otherwise wouldn't be.
I've tried to recreate the problem using the specific linker options
(-pie and -Bstatic), but that didn't make any difference for me; it
still resolved the branch to a blx.
> This is now looking more like U-Boot build infrastructure issue. Maybe,
> I should take this up in the U-Boot mailing list now?
I can see two options here: either there's something weird going on in
one of the parts I cannot reproduce, or else there's some bug in the
version of the linker you're using. So I'm wondering:
- Can you send me the full set of files (.o files, u-boot.lds linker
script, exact full command line etc.) for me to be able to run the
actual link command myself?
- What version of the linker are you using? Can you retry the link
on a native ARM Ubuntu Natty system using the system linker?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: ARM: Support for VFP/NEON registers in coredumps
Dave Martin wrote: > c) Create a new note type specially for this, and dump the > VFP/NEON regs in there. This is closest to the model followed > by ptrace, where PTRACE_GETREGS, PTRACE_GETFPREGS and > PTRAGE_GETVFPREGS are all distinct. >From a GDB perspective, I'd consider this the preferred solution; there are precedents for this on other platforms (e.g. PowerPC), and there is existing GDB/BFD infrastructure to check for presence/ absence of such notes. However, we also need to be able to distinguish the various cases: VFPv2 vs. VFPv3-D16 vs. VFPv3-D32 vs. VFPv32-D32+NEON These cause GDB to display/interact with the register set in different ways ... To distinguish 16 vs. 32 registers, we can of course simply look at the size of the note. But how to detect support for NEON as opposed to plain VFPv32-D32? I could think of two ways: 1) Have *two* new note types, one for VFP, and one for NEON 2) Have GDB look into the AT_HWCAP setting in the NT_AUXV note Option 2) seems preferable to me, since NT_AUXV is already there, and it can also be used to detect the integer-only NEON case. Thoughts? Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: ARM: Support for VFP/NEON registers in coredumps
Dave Martin wrote: > On Thu, Mar 24, 2011 at 2:57 PM, Ulrich Weigand wrote: > > 1) Have *two* new note types, one for VFP, and one for NEON > > That may not make sense, since really it's a single register file > shared by VFP and NEON. With NEON, you always have 32 x 64-bit regs, > but it's possible (although rare) to have this many regs on ARMv7 even > if NEON is absent. OK, agreed. > > 2) Have GDB look into the AT_HWCAP setting in the NT_AUXV note > > > > Option 2) seems preferable to me, since NT_AUXV is already there, > > and it can also be used to detect the integer-only NEON case. > > We could also dump the relevant hardware capability registers, which > can be more informative, though I'm in two minds about whether this is > appropriate / beneficial. A layout something like this might work: > > NT_VFPREGSET* > > unsigned long flags; > unsigned long feature_registers[3]; > unsigned long fpscr; > unsigned long long regs[16 or 32]; > > There are currently 3 relevant feature registers, the main > floating-point ID register FPSID, and the floating-point / SIMD > feature registers MVFR0, MVFR1. > > In either case, we define the contents of the flags field in such a > way as to allow gdb to understand the format, and to allow for future > expansion if this is ever needed. > > (*The note types seem to use different names in linux/elf.h compared > with /usr/include/elf.h and GDB. I've followed the outside world's > convention here.) I would prefer to keep the contents of NT_VFPREGSET identical to the contents of the PTRACE_GETVPFREGS/PTRACE_SETVPFREGS buffer: - This would allow implementation via the new generic user_regset_view mechanism (which the ARM kernel doesn't use yet, but probably should) - In any case, GDB likes to have the same set of information available when debugging core files and native targets So if there is indeed additional information that would be interesting, I'd argue this should be presented as a *new* core file note, *and* as a new set of PTRACE_... APIs. (But for GDB's purpose NT_AUXV right now is sufficent. Everything else could be displayed to the user if of interest.) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: ARM: Support for VFP/NEON registers in coredumps
Dave Martin wrote: > On Thu, Mar 24, 2011 at 4:40 PM, Ulrich Weigand wrote: > > I would prefer to keep the contents of NT_VFPREGSET identical to the > > contents of the PTRACE_GETVPFREGS/PTRACE_SETVPFREGS buffer: > > > > - This would allow implementation via the new generic user_regset_view > > mechanism (which the ARM kernel doesn't use yet, but probably should) > > > > - In any case, GDB likes to have the same set of information available > > when debugging core files and native targets > > > > So if there is indeed additional information that would be interesting, > > I'd argue this should be presented as a *new* core file note, *and* as > > a new set of PTRACE_... APIs. (But for GDB's purpose NT_AUXV right > > now is sufficent. Everything else could be displayed to the user if > > of interest.) > > OK, that sounds reasonable. > > If I'm reading the kernel code correctly, the size of the data > returned by PTRACE_GETVFPREGS is already dependent on the number of > registers (D16/D32) implemented by the hardware, and this is > determinable from the auxv contents; so I guess we don't have a new > problem to solve here. > > The other info can always be added in a later pass, if it looks like > it would be useful... OK, agreed. So to summarize: the kernel will write additional note sections as if generated via user_regset_view, containing the PTRACE_GETVFPREGS data. Note name: "LINUX" Note type: t.b.d. [*] [*] Looking at elf.h a logical name/value might be: #define NT_ARM_VFP 0x400 /* ARM VFP/NEON registers */ GDB support along those lines ought to be straightforward. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: ARM: Support for VFP/NEON registers in coredumps
Dave Martin wrote: > > So to summarize: the kernel will write additional note sections as if > > generated via user_regset_view, containing the PTRACE_GETVFPREGS data. > > > > Note name: "LINUX" > > Why "LINUX" and not "CORE"? I don't understand the distinction... are > the "CORE" notes common to all platforms / all ELF implementations? Because that's what user_regset_view would do; all notes except the standard ones (NT_PRPSINFO, NT_PRSTATUS, NT_PRFPREG, NT_AUXV) have a note name of "LINUX". I'm not completely sure about the rationale, but presumably it is indeed because the standard notes are more or less common across multiple platforms. > > Note type: t.b.d. [*] > > > > [*] Looking at elf.h a logical name/value might be: > > > > #define NT_ARM_VFP 0x400 /* ARM VFP/NEON registers */ > > > > > > GDB support along those lines ought to be straightforward. > > It's been suggested that the new note should include a version/flags > field alongside the ptrace-like register dump, so that if the format > turns out to be inadequate / broken, it can be extended in a > compatible way. > > However, nothing else in the coredump or the ptrace interface seems to > have such versioning implementation. Ptrace gets extended by adding > more and more ptrace call types instead. Adding version fields, while > sensible, seems inconsistent with the current implementation. > > What's your view on adding a flags field to the VFP state dump? Again, if we want to use (or mimic) the user_regset_view mechanism, there is no choice in any of this; the content of the note will be exactly identical to the content of the ptrace buffer. Since this is the way everybody else is using, I think we'd have to have really good arguments for deviating from it; I'm not sure I see those. The usual way to deal with changes to the register set is to define *new* regset structures, which then translates to new ptrace commands and new core files notes, which are used instead of or in addition to the old ones ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: ARM: Support for VFP/NEON registers in coredumps
Dave Martin wrote: > I was indeed thinking that it might be a good idea to take this > opportunity to migrate to using regsets; though for simplicity, I'll > probably avoid this for the first iteration. > > Will this have any impact on the ptrace interface? Well, once you support regsets, the PTRACE_GETREGSET/PTRACE_SETREGSET commands will start working. However, on platforms that already had commands to access registers, platform-specific code will of course need to continue to support those. See e.g. arch/powerpc/kernel/ptrace.c, which by now implements all of its legacy ptrace register commands in terms of regset functions. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
