Re: Problems with bfd: could it parse bin file built on arm64?
Hi 孟祥炜, 0 any bugs or errors in my using? The BFD library supports a large number of different architectures, but usually programs that use it are configured to only support a limited subset of these architectures. Often this is limited to just the host architecture. So for example if you were to use the objdump program on an x86_64 host machine you might see output like this: % objdump --help [...] objdump: supported targets: elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64 pei-i386 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big elf32-little elf32-big pe-x86-64 pe-bigobj-x86-64 pe-i386 srec symbolsrec verilog tekhex binary ihex plugin objdump: supported architectures: i386 i386:x86-64 i386:x64-32 i8086 i386:intel i386:x86-64:intel i386:x64-32:intel i386:nacl i386:x86-64:nacl i386:x64-32:nacl iamcu iamcu:intel l1om l1om:intel k1om k1om:intel [...] Note how there are lots of different target formats supported, but they are all x86 related. None of them are ARM related. So in order to support arm64 you either want to use a BFD library that has been built to run on an arm64 host (and of course run your program on that arm64 host too), or else you need to build your own version of the BFD library that has been configured to support arm64 as well as any other formats that you care about. To configure and build a BFD library with multiple different target support you need to obtain the binutils sources and then use a configure option to choose the targets. For example: /configure --enable-64-bit-bfd --enable-targets=aarch64-linux-gnu,x86_64-linux-gnu If you are not sure which targets you will need to support, you can configure the library to handle all of them: /configure --enable-64-bit-bfd --enable-targets=all I hope that this helps. Cheers Nick
[Bug gas/28262] Add warning when generating code in data section
https://sourceware.org/bugzilla/show_bug.cgi?id=28262 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Dietmar May from comment #0) Hi Dietmar, > If assembler code exists within a section that does not have a flags > argument, and does not have a "well known" name (like ".init" or ".text"), > it is assembled and silently placed within a data section. I guess it depends upon what you mean by a data section. If you mean a section with the PROGBITS type and the ALLOC and WRITE flags, then I would agree. But to be clear such a section will not have the EXECUTE flag. (I am restricting myself to ELF here, but similar concepts exist for other file formats). > ld will happily link the code, and the code will execute; Are you sure about this ? If the code is in a non-executable section then it should be linked into a non-executable segment, and so it should never be run. Do you have an example to demonstrate the behaviour you describe ? > The warning would only be emitted in the case where a section contains > executable code, Well I am not convinced enough of the utility of this warning to want to implement it myself, but if someone volunteers I am not going to object... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28266] CWD present in object file even after use of -fdebug-prefix-map=$PWD=foo
https://sourceware.org/bugzilla/show_bug.cgi?id=28266 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- (In reply to Joel Rosdahl from comment #0) Hi Joel, > I'm the maintainer of ccache, An excellent tool - I use it a lot myself. > My best guess is that this is due to > binutils commit 3417bfca676ff0b440f070a09837813e99b2c731 which seems to > unconditionally add CWD to the object file, hence filing this on the GAS > component. This makes sense. > Is it expected that the 0'th entry in the directory table is not rewritten > with -fdebug-prefix-map? I feel so. The -fdebug-prefix-map option predates DWARF-5 by quite a lot, so the interactions are not defined. But I think that the intention matches your expectations: > If not, I guess it breaks the intention of > -fdebug-prefix-map which is "This can give more reproducible builds, which > are location independent"? Right. So I would favour the interpretation that -fdebug-prefix-map is expected to override strict conformance to the DWARF standard because of the desire/need for reproducible builds. > I also noticed that 3417bfca676ff0b440f070a09837813e99b2c731 adds this > comment: > > /* In DWARF-5 the 0 entry in the directory table is expected to be >the same as the DW_AT_comp_dir (which is set to the current build >directory). Since we are about to create a directory entry that >is not the same, allocate the current directory first. >FIXME: Alternatively we could generate an error message here. */ > > However, the 0'th entry in the directory table won't always be the same as > DW_AT_comp_dir since the latter value is rewritten by -fdebug-prefix-map. True. Possibly it can be argued that in the presence of the -fdebug- prefix-map option the DW_AT_comp_dir entry ought to be changed as well. (Which would match the intention of creating reproducible builds). The problem with this idea is that it is GCC not GAS that generates the DW_AT_comp_dir entry, and detecting it reliably in the assembler would quite hard. But maybe GCC can be persuaded to do this instead ? > Another data point is that Clang in Fedora 34 sets the 0'th directory > entry with -fdebug-prefix-map applied. So gas and Clang are in sync on this ? Good. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28292] v850-elf-ld: Opcode "st.b" is cracked in relocation process
https://sourceware.org/bugzilla/show_bug.cgi?id=28292 Tetsuma Hoshino changed: What|Removed |Added CC||t-hosh...@pony-e.jp -- You are receiving this mail because: You are on the CC list for the bug.
