Re: Error: attempt to get value of unresolved symbol `L0'
On Tuesday 11 October 2022 08:46:58 Richard Biener wrote:
> On Mon, Oct 10, 2022 at 7:19 PM Pali Rohár via Gcc wrote:
> >
> > Hello!
> >
> > During development and debugging of U-Boot bootloader I got strange
> > error from ARM GNU assembler, which looks like a bug in binutils or gcc.
> >
> > Below is simplified code which can trigger it:
> >
> > $ cat test.S
> > kernoffs:
> > .word KERNEL_OFFSET - (. - CONFIG_SYS_TEXT_BASE)
> >
> > $ arm-linux-gnueabi-gcc -DKERNEL_OFFSET=0x4
> > -DCONFIG_SYS_TEXT_BASE=0x80008000 -pipe -c test.S
> > {standard input}: Assembler messages:
> > {standard input}: Error: attempt to get value of unresolved symbol `L0'
> >
> > I do not use any L0 symbol in the code, so error message seems to be
> > incorrect. And also I do not think that there is issue in that simple
> > assembler code.
>
> You are using (. - CONFIG_SYS_TEXT_BASE) where '.' is the "current"
> address, that's where L0 (a local label) gets introduced internally. I think
> this is an assembler issue or this use is not supported. Simplified testcase:
>
> > cat t.s
> kernoffs:
> .word - (. - 0x80008000)
> > as -o t.o t.s
> t.s: Assembler messages:
> t.s: Error: attempt to get value of unresolved symbol `L0'
>
> Richard.
Interesting... Another test case which is working fine:
kernoffs:
.word 0x4 - (. - 0x0)
So which use case could not be supported? I still do not see pattern
what can be accepted and what not.
I have feeling that this is assembler issue somewhere...
> >
> > On the other hand, if I declare negated value then compilation passes
> > without any error/warning. Code is:
> >
> > kernoffs:
> > .word . - CONFIG_SYS_TEXT_BASE - KERNEL_OFFSET
> >
> > It is quite strange that negated value can be compiled by gcc/as without
> > issue here.
> >
> > I was told that I should report this issue, so I'm sending email to
> > binutils and gcc mailing list.
> >
> > Do you have any idea where is the issue? It is a bug in gcc / as or is
> > there some syntax / semantic error in that simple example?
> >
> > Just for the record I'm using standard ARM cross compiler available on
> > Debian 10 Buster system. Here are version information:
> >
> > $ arm-linux-gnueabi-gcc -v
> > Using built-in specs.
> > COLLECT_GCC=arm-linux-gnueabi-gcc
> > COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabi/8/lto-wrapper
> > Target: arm-linux-gnueabi
> > Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-2'
> > --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
> > --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
> > --with-gcc-major-version-only --program-suffix=-8 --enable-shared
> > --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
> > --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
> > --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> > --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> > --disable-libitm --disable-libquadmath --disable-libquadmath-support
> > --enable-plugin --enable-default-pie --with-system-zlib
> > --with-target-system-zlib --enable-multiarch --disable-sjlj-exceptions
> > --with-arch=armv5te --with-float=soft --disable-werror
> > --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> > --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi-
> > --includedir=/usr/arm-linux-gnueabi/include
> > Thread model: posix
> > gcc version 8.3.0 (Debian 8.3.0-2)
> >
> > $ arm-linux-gnueabi-as --version
> > GNU assembler (GNU Binutils for Debian) 2.31.1
> > Copyright (C) 2018 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the terms of
> > the GNU General Public License version 3 or later.
> > This program has absolutely no warranty.
> > This assembler was configured for a target of `arm-linux-gnueabi'.
how to handle the frame_info and stack of various variable length MACHINE_MODE?
Hi, I have some questions about the frame_info and stack of variable length type: In the current gcc framework, it seems that 'poly_uint64(coeff0, coeff1)' is used to calculate 'cfun->machine->frame', but only one variable length type(vector) can be processed. If I want to add a new variable length type, such as matrix type, how can I handle its frame_info and stack? In other words, how to handle the frame_info and stack of various variable length MACHINE_MODE. Thanks.
Re: Error: attempt to get value of unresolved symbol `L0'
Hi Pali, Hi Richard, Interesting... Another test case which is working fine: kernoffs: .word 0x4 - (. - 0x0) This works because this expression can be converted into an instruction and a relocation in the object file: % as t.s -o t.o % objdump -dr t.o Disassembly of section .text: : 0: 0003fffc.word 0x0003fffc 0: R_ARM_REL32 *ABS* Which shows that when this object file is linked the word at offset 0 inside the .text section should be converted into an absolute value of (pc - 0x4000), where pc is the address of the word. This instruction however: .word - (. - 0x80008000) Cannot be converted since the linker would need to compute ((pc - 0x800800) * -1) which cannot be expressed by a single relocation. Similarly: .word KERNEL_OFFSET - (. - CONFIG_SYS_TEXT_BASE) Cannot be expressed by a single value, modified by a single relocation, even when the KERNEL_OFFSET and CONFIG_SYS_TEXT_BASE values are known at assembly time. A clever assembler might be able to rearrange the expression, assuming that overflow is unimportant, but gas does not do that. But just for reference the following would work: .word KERNEL_OFFSET + CONFIG_SYS_TEXT_BASE - . I agree however that this message: t.s: Error: attempt to get value of unresolved symbol `L0' is unhelpful. So I am going to check in a patch to change it to: t.s: Error: expression is too complex to be resolved I looked into providing a file name and line number with the error message, but this would involve reworking a lot of the assembler's internal expression parser. Cheers Nick
Re: Error: attempt to get value of unresolved symbol `L0'
On Tue, Oct 11, 2022 at 12:37 PM Nick Clifton wrote: > > Hi Pali, Hi Richard, > > > Interesting... Another test case which is working fine: > > > >kernoffs: > >.word 0x4 - (. - 0x0) > > This works because this expression can be converted into an instruction > and a relocation in the object file: > >% as t.s -o t.o >% objdump -dr t.o >Disassembly of section .text: > > : > 0: 0003fffc.word 0x0003fffc > 0: R_ARM_REL32 *ABS* > > Which shows that when this object file is linked the word at offset 0 > inside the .text section should be converted into an absolute value of > (pc - 0x4000), where pc is the address of the word. > > This instruction however: > > .word - (. - 0x80008000) > > Cannot be converted since the linker would need to compute ((pc - 0x800800) * > -1) > which cannot be expressed by a single relocation. Similarly: > > .word KERNEL_OFFSET - (. - CONFIG_SYS_TEXT_BASE) > > Cannot be expressed by a single value, modified by a single relocation, even > when the KERNEL_OFFSET and CONFIG_SYS_TEXT_BASE values are known at assembly > time. > > A clever assembler might be able to rearrange the expression, assuming that > overflow is unimportant, but gas does not do that. But just for reference > the following would work: > > .word KERNEL_OFFSET + CONFIG_SYS_TEXT_BASE - . > > > I agree however that this message: > > t.s: Error: attempt to get value of unresolved symbol `L0' > > is unhelpful. So I am going to check in a patch to change it to: > > t.s: Error: expression is too complex to be resolved > > I looked into providing a file name and line number with the error > message, but this would involve reworking a lot of the assembler's > internal expression parser. GCC has a global input_location conveniently available when all other bets are off. Maybe mention "relocation" in the error message somehow? So "expression is too complex to be resolved by a single relocation"? Richard. > > Cheers >Nick >
Re: Error: attempt to get value of unresolved symbol `L0'
On Tuesday 11 October 2022 11:37:03 Nick Clifton wrote: > Hi Pali, Hi Richard, > > > Interesting... Another test case which is working fine: > > > >kernoffs: > >.word 0x4 - (. - 0x0) > > This works because this expression can be converted into an instruction > and a relocation in the object file: > > % as t.s -o t.o > % objdump -dr t.o > Disassembly of section .text: > > : >0: 0003fffc.word 0x0003fffc > 0: R_ARM_REL32 *ABS* > > Which shows that when this object file is linked the word at offset 0 > inside the .text section should be converted into an absolute value of > (pc - 0x4000), where pc is the address of the word. > > This instruction however: > > .word - (. - 0x80008000) > > Cannot be converted since the linker would need to compute ((pc - 0x800800) * > -1) > which cannot be expressed by a single relocation. Similarly: > > .word KERNEL_OFFSET - (. - CONFIG_SYS_TEXT_BASE) > > Cannot be expressed by a single value, modified by a single relocation, even > when the KERNEL_OFFSET and CONFIG_SYS_TEXT_BASE values are known at assembly > time. Hello! Thank you for this information. I would suggest to extend GAS documentation to include this kind of information into . (dot) usage as it is not really obvious that simple form with just addition and minus operations results in something complex with multiplication. And also that multiplication cannot be used in dot usage. > A clever assembler might be able to rearrange the expression, assuming that > overflow is unimportant, but gas does not do that. This looks like some useful feature which is not supported... > But just for reference the following would work: > > .word KERNEL_OFFSET + CONFIG_SYS_TEXT_BASE - . > > > I agree however that this message: > > t.s: Error: attempt to get value of unresolved symbol `L0' > > is unhelpful. So I am going to check in a patch to change it to: > > t.s: Error: expression is too complex to be resolved Perfect, that would be better. > I looked into providing a file name and line number with the error > message, but this would involve reworking a lot of the assembler's > internal expression parser. Having file name and line number would be also useful as it took me some time to figure out where is the issue... > > Cheers > Nick >
Re: [PATCH RESEND 1/1] p1689r5: initial support
On Tue, Oct 04, 2022 at 21:12:03 +0200, Harald Anlauf wrote:
> Am 04.10.22 um 17:12 schrieb Ben Boeckel:
> > This patch implements support for [P1689R5][] to communicate to a build
> > system the C++20 module dependencies to build systems so that they may
> > build `.gcm` files in the proper order.
>
> Is there a reason that you are touching so many frontends?
Just those that needed the update for `cpp_finish`. It does align with
those that will (eventually) need this support anyways (AFAIK).
> > diff --git a/gcc/fortran/cpp.cc b/gcc/fortran/cpp.cc
> > index 364bd0d2a85..0b9df9c02cd 100644
> > --- a/gcc/fortran/cpp.cc
> > +++ b/gcc/fortran/cpp.cc
> > @@ -712,7 +712,7 @@ gfc_cpp_done (void)
> > FILE *f = fopen (gfc_cpp_option.deps_filename, "w");
> > if (f)
> > {
> > - cpp_finish (cpp_in, f);
> > + cpp_finish (cpp_in, f, NULL);
> > fclose (f);
> > }
> > else
> > @@ -721,7 +721,7 @@ gfc_cpp_done (void)
> > xstrerror (errno));
> > }
> > else
> > - cpp_finish (cpp_in, stdout);
> > + cpp_finish (cpp_in, stdout, NULL);
> > }
> >
> > cpp_undef_all (cpp_in);
>
> Couldn't you simply default the third argument of cpp_finish() to NULL?
I could do that. Wasn't sure how much that would be acceptable given
that it is a "silent" change, but it would reduce the number of files
touched here.
Thanks,
--Ben
Re: [PATCH RESEND 1/1] p1689r5: initial support
On Mon, Oct 10, 2022 at 17:04:09 -0400, Jason Merrill wrote:
> On 10/4/22 11:12, Ben Boeckel wrote:
> > This patch implements support for [P1689R5][] to communicate to a build
> > system the C++20 module dependencies to build systems so that they may
> > build `.gcm` files in the proper order.
>
> Thanks!
>
> > Support is communicated through the following three new flags:
> >
> > - `-fdeps-format=` specifies the format for the output. Currently named
> >`p1689r5`.
> >
> > - `-fdeps-file=` specifies the path to the file to write the format to.
>
> Do you expect users to want to emit Makefile (-MM) and P1689
> dependencies from the same compilation?
Yes, the build system wants to know what files affect scanning as well
(e.g., `#include ` is still possible and if it changes, this
operation should be performed again. The `-M` flags do this quite nicely
already :) .
> > - `-fdep-output=` specifies the `.o` that will be written for the TU
> >that is scanned. This is required so that the build system can
> >correlate the dependency output with the actual compilation that will
> >occur.
>
> The dependency machinery already needs to be able to figure out the name
> of the output file, can't we reuse that instead of specifying it on the
> command line?
This is how it determines the output of the compilation. Because it is
piggy-backing on the `-E` flag, the `-o` flag specifies the output of
the preprocessed source (purely a side-effect right now).
> > diff --git a/libcpp/include/cpplib.h b/libcpp/include/cpplib.h
> > index 2db1e9cbdfb..90787230a9e 100644
> > --- a/libcpp/include/cpplib.h
> > +++ b/libcpp/include/cpplib.h
> > @@ -298,6 +298,9 @@ typedef CPPCHAR_SIGNED_T cppchar_signed_t;
> > /* Style of header dependencies to generate. */
> > enum cpp_deps_style { DEPS_NONE = 0, DEPS_USER, DEPS_SYSTEM };
> >
> > +/* Format of header dependencies to generate. */
> > +enum cpp_deps_format { DEPS_FMT_NONE = 0, DEPS_FMT_P1689R5 };
>
> Why not add this to cpp_deps_style?
It is orthogonal. The `-M` flags and `-fdeps-*` flags are similar, but
`-fdeps-*` dependencies are fundamentally different than `-M`
dependencies. The comment does need updated though.
`-M` is about discovered dependencies: those that you find out while
doing work. `-fdep-*` is about ordering dependencies: extracting
information from file content in order to even order future work around.
It stems from the loss of embarassing parallelism when building C++20
code that uses `import`. It's isomorphic to the Fortran module
compilation ordering problem.
> > @@ -387,7 +410,7 @@ make_write_vec (const mkdeps::vec &vec,
> > FILE *fp,
> > .PHONY targets for all the dependencies too. */
> >
> > static void
> > -make_write (const cpp_reader *pfile, FILE *fp, unsigned int colmax)
> > +make_write (const cpp_reader *pfile, FILE *fp, unsigned int colmax, int
> > extra)
>
> Instead of adding the "extra" parameter...
Hmm. Not sure why I had named this so poorly. Maybe this comes from my
initial stab at this functionality in 2019 (the format has been hammered
out in ISO C++'s SG15 since then).
> > {
> > const mkdeps *d = pfile->deps;
> >
> > @@ -398,7 +421,7 @@ make_write (const cpp_reader *pfile, FILE *fp, unsigned
> > int colmax)
> > if (d->deps.size ())
> > {
> > column = make_write_vec (d->targets, fp, 0, colmax, d->quote_lwm);
> > - if (CPP_OPTION (pfile, deps.modules) && d->cmi_name)
> > + if (extra && CPP_OPTION (pfile, deps.modules) && d->cmi_name)
> > column = make_write_name (d->cmi_name, fp, column, colmax);
> > fputs (":", fp);
> > column++;
> > @@ -412,7 +435,7 @@ make_write (const cpp_reader *pfile, FILE *fp, unsigned
> > int colmax)
> > if (!CPP_OPTION (pfile, deps.modules))
> > return;
>
> ...how about checking CPP_OPTION for p1689r5 mode here?
I'll take a look at this.
> >
> > - if (d->modules.size ())
> > + if (extra && d->modules.size ())
> > {
> > column = make_write_vec (d->targets, fp, 0, colmax, d->quote_lwm);
> > if (d->cmi_name)
> > @@ -423,7 +446,7 @@ make_write (const cpp_reader *pfile, FILE *fp, unsigned
> > int colmax)
> > fputs ("\n", fp);
> > }
> >
> > - if (d->module_name)
> > + if (extra && d->module_name)
> > {
> > if (d->cmi_name)
> > {
> > @@ -455,7 +478,7 @@ make_write (const cpp_reader *pfile, FILE *fp, unsigned
> > int colmax)
> > }
> > }
> >
> > - if (d->modules.size ())
> > + if (extra && d->modules.size ())
> > {
> > column = fprintf (fp, "CXX_IMPORTS +=");
> > make_write_vec (d->modules, fp, column, colmax, 0, ".c++m");
> > @@ -468,9 +491,203 @@ make_write (const cpp_reader *pfile, FILE *fp,
> > unsigned int colmax)
> > /* Really we should be opening fp here. */
> >
> > void
> > -deps_write (const cpp_reader *pfile, FILE *fp, unsigned int colmax)
> > +deps_write (const struct cpp_reader *pfi
Issue with dllexport/dllimport inline function
Hi,
I'm trying to dllexport/dllimport an inline function, but I get this
warning:
```
inline function ‘g_strcmp0’ declared as dllimport: attribute ignored [-
Wattributes]
```
This is when cross compiling my code on Linux for Windows using mingw.
The relevant code is
```
GLIB_API inline
int g_strcmp0 (const char *str1,
const char *str2)
{
if (!str1)
return -(str1 != str2);
if (!str2)
return str1 != str2;
return strcmp (str1, str2);
}
```
Where GLIB_API is defined to `__declspec(dllexport)` when compiling the
DLL and `__declspec(dllimport)` when including the header from
application.
The goal is to get that function inlined when doing `if (g_strcmp0(a,
b))`, but get address from instance in the DLL when doing
`do_sort(array, g_strcmp0)`.
I believe dllimport of inline function should be supported, it compiles
fine with MSVC. It is even documented there:
https://learn.microsoft.com/en-us/cpp/cpp/defining-inline-cpp-functions-with-dllexport-and-dllimport?view=msvc-170
I believe (but not tested myself) that clang had the same issue but got
fixed years ago: https://reviews.llvm.org/D3772
For context, I'm hitting this issue when working on that GLib patch:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2926
Is there a trick to get that working with GCC? Or should that issue be
reported somewhere?
Regards,
Xavier Claessens
Re: The GNU Toolchain Infrastructure Project
On 2022-10-06 18:57, Frank Ch. Eigler wrote: [...] so that we continue to have them involved in the technical direction of GNU toolchain infrastructure? [...] "continue"? If the nature & degree of involvement we had so far in the LF/GTI process is representative of the future, I'm not sure I can in good faith ask anyone to fund our time on that. Given that you are listed as a TAC member, yet admitted being unclear on some details of the proposal itself, perhaps we're in the same boat. Yes we are, in the sense that this is a proposal and the details are upon us (you're a listed member of TAC too) to help finalize. Sid
Re: Issue with dllexport/dllimport inline function
Le mardi 11 octobre 2022 à 13:00 +0800, LIU Hao a écrit :
> you may try
>
> ```
> __attribute__((__gnu_inline__))
> extern inline
> int g_strcmp0(const char*, const char*)
> { ...
> ```
Thanks, I gave that a try but I get many: multiple definition of
`g_strcmp0'. But at least the warning about dllimport is now gone.
> In contrast to C, you don't need the `extern` in C++.
>
> When this function is being defined in a DLL, `__dllexport__` should
> be used in place of
> `__gnu_inline__`. This may require another macro, similar to
> `GLIB_API`.
Re: Issue with dllexport/dllimport inline function
在 2022/10/11 21:10, xclae...@gmail.com 写道:
Le mardi 11 octobre 2022 à 13:00 +0800, LIU Hao a écrit :
you may try
```
__attribute__((__gnu_inline__))
extern inline
int g_strcmp0(const char*, const char*)
{ ...
```
Thanks, I gave that a try but I get many: multiple definition of
`g_strcmp0'. But at least the warning about dllimport is now gone.
Did you have any declarations that had no `__gnu_inline__`? GNU inline functions are supposed to be
emitted out of line, even when its address is taken.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
Re: Issue with dllexport/dllimport inline function
在 2022/10/11 21:28, LIU Hao via Gcc 写道: Did you have any declarations that had no `__gnu_inline__`? GNU inline functions are supposed to be emitted out of line, even when its address is taken. This should be 'to be never emitted out of line'. Sorry for that. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature
Re: The GNU Toolchain Infrastructure Project
Hi - > [...] As for the rest, it really is a question on whether all of > sourceware will in the end be migrated over to LF, it's for the > remaining projects to decide. If we indeed have all projects on > board [...] "we" do not. That option was taken off the table weeks ago. For that matter, I have not seen -any- project decisionmaking bodies formally announce to/with their developer communities that they wished to move away, only a few individuals who propose that this be done. - FChE
Re: Issue with dllexport/dllimport inline function
Le mardi 11 octobre 2022 à 21:35 +0800, LIU Hao a écrit :
> 在 2022/10/11 21:28, LIU Hao via Gcc 写道:
> >
> > Did you have any declarations that had no `__gnu_inline__`? GNU
> > inline functions are supposed to be
> > emitted out of line, even when its address is taken.
> >
>
> This should be 'to be never emitted out of line'. Sorry for that.
I have one .c file, part of libglib-2.0-0.dll, that has that line:
```
extern int g_strcmp0 (const char *str1, const char *str2);
```
The header file has that:
```
GLIB_INLINE
int g_strcmp0 (const char *str1,
const char *str2)
{
if (!str1)
return -(str1 != str2);
if (!str2)
return str1 != str2;
return strcmp (str1, str2);
}
```
I now define GLIB_INLINE that way:
```
#if (defined(_WIN32) || defined(__CYGWIN__)) &&
!defined(GLIB_STATIC_COMPILATION)
# define _GLIB_EXPORT __declspec(dllexport)
# define _GLIB_IMPORT __declspec(dllimport)
#elif __GNUC__ >= 4
# define _GLIB_EXPORT __attribute__((visibility("default")))
# define _GLIB_IMPORT
#else
# define _GLIB_EXPORT
# define _GLIB_IMPORT
#endif
#ifdef GLIB_COMPILATION
# define _GLIB_API _GLIB_EXPORT
# define GLIB_INLINE __attribute__((__dllexport__))
__attribute__((__gnu_inline__)) extern inline
#else
# define _GLIB_API _GLIB_IMPORT
# if defined(__has_attribute) && __has_attribute(__gnu_inline__)
// https://gcc.gnu.org/pipermail/gcc/2022-October/239592.html
#define GLIB_INLINE __attribute__((__gnu_inline__)) extern inline
# else
#define GLIB_INLINE _GLIB_EXPORT extern inline
# endif
#endif
```
`GLIB_COMPILATION` is defined when compiling libglib-2.0-0.dll but not
when compiling other dlls or applications.
The linker issue actually happens when linking libglib-2.0-0.dll,
multiple definition happens for all .c files that actually uses
g_strcmp0:
```
/usr/bin/x86_64-w64-mingw32-ld: glib/libglib-2.0-
0.dll.p/deprecated_grel.c.obj: in function `g_strcmp0':
/home/xclaesse/programmation/glib/builddir/../glib/gtestutils.h:245:
multiple definition of `g_strcmp0'; glib/libglib-2.0-
0.dll.p/deprecated_gcache.c.obj:/home/xclaesse/programmation/glib/build
dir/../glib/gtestutils.h:245: first defined here
```
Re: Error: attempt to get value of unresolved symbol `L0'
Hi Pali, Hi Richard, Having file name and line number would be also useful as it took me some time to figure out where is the issue... Right - I have tried a little harder and come up with a follow up patch. This is now checked in, and given an input file that looks like this: % cat t.s kernoff: .set KERNEL_OFFSET, 0x4 .set CONFIG_SYS_TEXT_BASE, 0x80008000 .word 44 .word KERNEL_OFFSET - (. - CONFIG_SYS_TEXT_BASE) .word - (. - 0x80008000) .word 0x4 - (. - 0x0) The assembler now produces the following output: t.s: Assembler messages: t.s:5: Error: expression is too complex to be resolved or converted into relocations t.s:6: Error: expression is too complex to be resolved or converted into relocations Note - some targets do support applying multiple relocations to a single address, but even then there can be expressions that cannot be resolved this way. That is why the error message refers to "converted into relocations" rather than just "converted into a relocation". Cheers Nick
Re: Error: attempt to get value of unresolved symbol `L0'
On Tuesday 11 October 2022 15:33:59 Nick Clifton wrote: > Hi Pali, Hi Richard, > > > Having file name and line number would be also useful as it took me > > some time to figure out where is the issue... > > Right - I have tried a little harder and come up with a follow up patch. > This is now checked in, and given an input file that looks like this: > > % cat t.s > kernoff: > .set KERNEL_OFFSET, 0x4 > .set CONFIG_SYS_TEXT_BASE, 0x80008000 > .word 44 > .word KERNEL_OFFSET - (. - CONFIG_SYS_TEXT_BASE) > .word - (. - 0x80008000) > .word 0x4 - (. - 0x0) > > The assembler now produces the following output: > > t.s: Assembler messages: > t.s:5: Error: expression is too complex to be resolved or converted into > relocations > t.s:6: Error: expression is too complex to be resolved or converted into > relocations > > Note - some targets do support applying multiple relocations to a > single address, but even then there can be expressions that cannot > be resolved this way. That is why the error message refers to > "converted into relocations" rather than just "converted into a > relocation". > > Cheers > Nick > Nice! Anyway, what should I use in code? .word . - CONFIG_SYS_TEXT_BASE - KERNEL_OFFSET or .word CONFIG_SYS_TEXT_BASE + KERNEL_OFFSET - . And can you guarantee that one of those form would work also in future gcc/binutils versions, and it is not something version specific or undocumented?
Re: Issue with dllexport/dllimport inline function
在 2022-10-11 22:26, xclae...@gmail.com 写道: #ifdef GLIB_COMPILATION # define _GLIB_API _GLIB_EXPORT # define GLIB_INLINE __attribute__((__dllexport__)) __attribute__((__gnu_inline__)) extern inline This is not correct. Typically, `dllexport` indicates that 'I want an external definition' but `gnu_inline` indicates that 'I do not want an external definition', so it's a contradiction: you get either multiple definitions, or none (which causes undefined references). To user code which imports such a function, it should be seen as ``` __attribute__((__gnu_inline__)) extern inline int g_strcmp0(const char*, const char*) ``` This has the desired effect: The function can be inlined where appropriate. And if not, a call to the external thunk is emitted; no weak definition is emitted in either case. To the library itself which exports it, it should be seen as ``` __attribute__((__dllexport__)) extern inline int g_strcmp0(const char*, const char*) ``` There is no `gnu_inline` in this case. GCC always generates a COMDAT/weak/linkonce definition, which will not cause multiple definition errors. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature
Re: The GNU Toolchain Infrastructure Project
Hi - > [...] Where was a statement from key members of the GNU Toolchain > projects -- the people who actually use the services and > infrastructure on a day to day basis for their participation in the > GNU Toolchain projects -- asking for an alternative proposal? When > were they allowed to participate in the preparation of the > "Sourceware" proposal, supposedly for their benefit? [...] This echoes a question asked during the Cauldron session. I believe it was during the second half, whose Zoom recording is for some reason still not published. Could you ask Jeremy to fix that please? Anyway, to try to recount what I said then: the SFC proposal is independent of the various guest projects. It does not pretend to speak for any of them. It does not impose any changes on them. All the guests are just as welcome to come, stay, and leave, as they have always been. For this reason, it was not necessary to draw a stakeholder map and conduct years-long negotiations behind the scenes. Everyone has been invited to advise, in public, since August 30. - FChE
Re: Issue with dllexport/dllimport inline function
Le mercredi 12 octobre 2022 à 01:42 +0800, LIU Hao a écrit : > 在 2022-10-11 22:26, xclae...@gmail.com 写道: > > #ifdef GLIB_COMPILATION > > # define _GLIB_API _GLIB_EXPORT > > # define GLIB_INLINE __attribute__((__dllexport__)) > > __attribute__((__gnu_inline__)) extern inline > > This is not correct. Typically, `dllexport` indicates that 'I want an > external definition' but > `gnu_inline` indicates that 'I do not want an external definition', > so it's a contradiction: you get > either multiple definitions, or none (which causes undefined > references). Sorry, that was a wrong copy/paste when writing the email (leftover of things I tried previously). I can confirm the multiple definition error I have is when that line is `# define GLIB_INLINE _GLIB_EXPORT extern inline`, which expands to `__declspec(dllexport) extern inline`. > To user code which imports such a function, it should be seen as > > ``` > __attribute__((__gnu_inline__)) > extern inline > int g_strcmp0(const char*, const char*) > ``` > > This has the desired effect: The function can be inlined where > appropriate. And if not, a call to > the external thunk is emitted; no weak definition is emitted in > either case. > > > To the library itself which exports it, it should be seen as > > ``` > __attribute__((__dllexport__)) > extern inline > int g_strcmp0(const char*, const char*) > ``` > > There is no `gnu_inline` in this case. GCC always generates a > COMDAT/weak/linkonce definition, which > will not cause multiple definition errors. Right, that's what I do and it fails. I made a simplified example: https://gitlab.gnome.org/xclaesse/inline-example Build it with: meson setup builddir --cross-file cross_file_mingw64.txt ninja -C builddir/ And it fails with: ``` x86_64-w64-mingw32-gcc -o libfoo.dll libfoo.dll.p/foo.c.obj libfoo.dll.p/bar.c.obj -Wl,--allow-shlib-undefined -shared -Wl,--start- group -Wl,--out-implib=libfoo.dll.a -fstack-protector -lkernel32 - luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid - lcomdlg32 -ladvapi32 -Wl,--end-group /usr/bin/x86_64-w64-mingw32-ld: libfoo.dll.p/bar.c.obj: in function `g_strcmp0': /home/xclaesse/programmation/inline-example/builddir/../foo.h:5: multiple definition of `g_strcmp0'; libfoo.dll.p/foo.c.obj:/home/xclaesse/programmation/inline- example/builddir/../foo.h:5: first defined here ``` Thanks for your help!
Re: Issue with dllexport/dllimport inline function
在 2022/10/12 02:37, xclae...@gmail.com 写道: Build it with: meson setup builddir --cross-file cross_file_mingw64.txt ninja -C builddir/ And it fails with: That's because you compiled it as C. I used g++ to compile these, and there was no such error. For C, this inline issue is going to be much more messy due to lack of COMDAT support about `inline`. Your will need a dedicated macro for each translation unit. A dirty solution looks like this: ``` #ifndef INSIDE_FOO_C __attribute__((__dllexport__)) inline #endif extern int g_strcmp0(const char*str1, const char*str2) ... ``` and in 'foo.c': ``` #define INSIDE_FOO_C 1 #include "foo.h" extern int g_strcmp0 (const char *str1, const char *str2); ``` Further reading: https://github.com/lhmouse/mcfgthread/wiki/Differences-between-GNU,-C99-and-C---%60inline%60 -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature
How to get started with the contribution
Respected Sir/ Mam , I am Zunzarrao Deore, a computer science undergrad. I have just entered my second year at D.Y. Patil college of engineering, Pune. I am new to open source contribution but I am well aware of programming languages like C++, Python, html and CSS also I have moderate knowledge of Data Structures and Algorithms. I would like to contribute to your organizations but could you tell me how to get started ? Hoping to hear from you soon. Regards Zunzarrao.
